|
|
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
kdv Например - в базе внезапные тормоза, работает запрос. В чем причина? Оказалось, что была длинная транзакция (чья-то, х.з.), после чего накопились тонны мусора, кто-то запустил запрос и в это время сработал репликатор (который программно собирает записи по всей базе), и началась адова сборка мусора. Определили причину трейсом плюс мон. Дим, сколько миллиардов записей должно быть в таблице, чтобы апдейт одного поля поштучно с where по уникальному индексу продолжался трое суток, даже на фоне адовой сборки? Там либо where с условием по блобам, либо с запросами к "другой" базе всё хорошо, прекрасная маркиза, либо база действительно после b/r уменьшается раз в 100, либо всё вместе :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2021, 19:52 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
Старый плюшевый мишка, "может быть всё что угодно!". Может админ в этот момент начал копировать подборку BD-фильмов с сервака. Кроме того, мы знаем, что если кто-то долбит writes в одни и те же страницы, то там сборка мусора плохо работает, в результате уборщица постоянно топчется на входе. Все это в сумме может растянуться на трое суток. Но скорее всего косяк в процедуре :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2021, 22:19 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
я еще добавлю. вот пялимся в mon$attachments, прибавляя статистику по страницам. Смотрим на коннект с процедурой. Если он делает page writes раз в 10 больше остальных коннектов, которые там часами сидят, то конечно это ненормально. Всё познается в сравнении. А не в каких-то непонятных "суммированиях за сутки". Потому что если процедура работает, то page writes уже есть, и для "оценки" нам надо было бы вернуться в прошлое на трое суток назад, и целый день смотреть в mon$. Короче, либо я не понял чего хочет автор, либо у автора нет понимания как производится и оценивается мониторинг сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2021, 22:38 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
Какие вы тут суровые. Автор уже почти ничего не хочет, он получил нужные ответы весьма быстро, за что искренне благодарен гуру. А дальше пошла дискуссия, в которой автор посчитал невежливым не участвовать, ибо сам запустил тему. И еще автору, то есть мне, непонятно, что непонятно осталось вам. Попробую еще раз, простыми словами. 1. Запустил процедуру. 2. Процедура не возвращается. Час не возвращается, другой не возвращается... Что делать? Вдруг она зациклилась, или ждет на suspend, или еще что? А может, и нормально работает, просто долго. Как узнать? 3. К счастью, известно, что процедура должна последовательно обновлять определенную таблицу. Из других транзакций изменения не видны, но сам факт наличия обновлений можно посмотреть из мониторинга (надеется автор). Коннектов всего два, один исполняет процедуру, другой мониторит. 4. Ура, есть такая штука, как PAGE_WRITES! Ну-ка, что там? 500. Что 500, чего 500? Вопрос на форум - ответ получен! Это 500 страниц обновлены с какого-то момента старта. Ладно, смотрим через минуту - 510, через 2 минуты - 520, через 3 минуты 530, равномерно и поступательно. Отлично, значит работа идет по плану, откладываем беспокойство, ждем результата. Собственно, все, ответы получены, проблема снята. А дальше философия: от абсолютного числа 500 проку никакого нет, и непонятно, когда и кому он может быть, если неизвестно время старта. Зато очень полезны разницы, через минуту, через час и пр. Да не вопрос, можно и руками разницы вычислить. Просто философия. kdv либо у автора нет понимания как производится и оценивается мониторинг сервера. Эт точно. Вот и набираюсь тут помаленьку. А где еще? В "Руководстве по языку" прочитал ровно то, что вынес в топик. Других документов, где рассказывалось бы про мониторинг, не видел, и на ibase.ru тоже. Наверное, плохо искал. А здесь хорошо, мне уже много рассказали, спасибо hvlad'у прежде всего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2021, 02:50 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
shalamyansky, гм. чтобы понимать мониторинг, надо понимать - разницу между архитектурами SS, CS/SC - что файл базы - это страничный файл произвольного доступа - что на страницах располагаются записи, ключи индексов, указатели, и прочее. - что у Firebird есть кэш, который наполняется и вытесняется - что есть таблицы мониторинга mon$, которые показывают состояние сервера. Вот. Сумма всех этих знаний дает нормальное понимание последнего пункта. Собственно, такую статью можно написать, но это очень скучно, и нынче такое читать непопулярно. Люди даже готовые средства мониторинга неохотно используют, а тут целую статью читать надо. А в общем во всех базах данных примерно одно и то же. Поэтому если есть понимание только SQL и Delphi, то понимание перечисленного выше никак не образуется, без чтения общих статей про базы данных. Ну и, например, зачем надо было в page_writes лезть, если можно было смотреть record_stats (например, MON$RECORD_SEQ_READS и MON$RECORD_UPDATES), с бОльшим успехом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2021, 03:08 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
shalamyansky2. Процедура не возвращается. Час не возвращается, другой не возвращается... Что делать? Прервать и переписать. shalamyanskyВдруг она зациклилась, или ждет на suspend, или еще что? А может, и нормально работает, просто долго. Как узнать? "Ждать на SUSPEND" процедура не может, этот процесс требует взаимодействия с клиентом, который её запустил. "Работает нормально, но долго"... Если процедура работает долго - это уже ненормально. Прервать и переписать. Кроме того, если процедура работает нормально, это видно по 100% загрузке серверного диска. Из мониторинга достаточно iotop/Task Manager. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2021, 13:42 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov Прервать и переписать. Мы у себя около полуночи отрубаем все коннекты, ибо нефиг. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2021, 13:52 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
Ivan_Pisarevsky Dimitry Sibiryakov Прервать и переписать. Дык этта... Любой естественный процесс, как известно, состоит из трёх фаз - for play, action, after play. Я так тоже привык основное внимание уделять for play, но есть и любители action до мозолей, а некоторым всё это пофиг, важно заняться after play с результатом :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2021, 16:32 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
shalamyansky 2. Процедура не возвращается. Час не возвращается, другой не возвращается... Что делать? Вдруг она зациклилась, или ждет на suspend, или еще что? А может, и нормально работает, просто долго. Как узнать? А, таки соломка в виде suspend после update таки положена? Открою маленький секрет - клиент увидит эти suspend-ы не сразу, а когда их наберётся достаточно толстая пачка чтобы заполнить стандартный сетевой пакет. И счётчик на клиенте резко прыгнет на размер пачки. Чтобы видеть их по одному и сразу, надо делать не select from procedure, а select for update from procedure. Но это затормозит естественный процесс. Не фатально, но заметно. У селективных процедур, изменяющих данные, есть ещё один прикол, но на него обычно наступают люди боле-мене искушённые. Суть его в том, что у людей, помнящих о мусоре и разрыве транзакций, есть привычка коммитить транзакции, если в них выполняются только селективные запросы или одиночный изменяющий данные оператор. Так вот, при коммите транзакции, в которой выполняется такая селективная процедура, уже suspend-нутые изменения зафиксируются в базе в случае возникновения исключения. В отличие от прямого update с клиента и execute неселективной процедуры, где всё будет отменено из-за исключения, независимо от способа завершения транзакции. Если логика обновления такого не допускает, надо плюнуть на принципы и сделать роллбак. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2021, 16:48 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov Прервать и переписать. Что-то вдруг задумался - а какие сейчас есть безопасные методы для "прервать"? Через mon$ таблицы? Можно тынцем или просто доку к какой версии почитать, когда появилось. В моё время на классике дело кончалось килянием серверного процесса, что ну ни разу не безопасно, а про супер просто не знаю, не пользовал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2021, 13:20 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
Старый плюшевый мишка безопасные методы для "прервать"? Через mon$ таблицы? Бывал грешен, не дожидался, килял сам процесс сервера, "веселых" последствий пока не огреб, но советовать килять сервер не стану. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2021, 13:29 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
Старый плюшевый мишкаа какие сейчас есть безопасные методы для "прервать"? Если приложение своё - fb_cancel_operation(). isql это делает автоматически по Ctrl-C. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2021, 14:04 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov Старый плюшевый мишкаа какие сейчас есть безопасные методы для "прервать"? Если приложение своё - fb_cancel_operation(). isql это делает автоматически по Ctrl-C. в том же коннекте? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2021, 13:56 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
Само собой, это же клиентский API-вызов. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2021, 14:29 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
kdv можно было смотреть record_stats (например, MON$RECORD_SEQ_READS и MON$RECORD_UPDATES), с бОльшим успехом. Логично. Схватился за первое, что попалось вроде подходящее. MON$IO_STATS по алфавиту раньше, чем MON$RECORD_STATS. Старый плюшевый мишка Открою маленький секрет Вот это спасибо. Маленькие секреты всегда хороши. Особенно, если в памяти остаются. Хотя бы в памяти остается факт существования маленького секрета. Всех с наступающим Новым Годом! Всем здравого по возможности ума и твердой памяти! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2021, 19:11 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
shalamyanskyСхватился за первое, что попалось вроде подходящее. MON$IO_STATS по алфавиту раньше, чем MON$RECORD_STATS. И точно так же бесполезны в твоём случае. Если у тебя FOR SELECT ON EDS, а внутри какой-нибудь UPDATE, то маленькая ошибочка в виде забытого условия в этом UPDATE будет упорно молотить всю таблицу, задирая количество записанных страниц до небес, а если таки дождаться результата, то он будет всё так же ужасом, после которого придётся восстанавливать базу из бэкапа. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2021, 19:28 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, Вам бы сценарии писать для сочельниковских ужастиков. Однако, статистика по обновлениям поможет и в этом кошмарном случае, ибо дикое число обновлений столь же греховно, сколь и полное их отсутствие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2021, 19:44 |
|
||
|
Мониторинг - статистики
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Само собой, это же клиентский API-вызов. ну мало ли... у кого то вроде через отдельный коннект было ок, вызов в том же коннекте... поясните кто в теме отправил я op_execute, что писать в сокет по истечении таймаута? нашел в драйвере константу op_cancel = 91, оно? отправили op_cancel с fb_cancel_raise (гошный драйвер про эти константы даже не в курсе), какой пакет(ы) придут (могут прийти) от сервера после? op_response в ответ на op_cancel а после op_response на op_execute со статусом cancelled? а наоборот может быть, если на момент отправки op_cancel сервер завершил выполнение запроса? как правильно потом прочитать ответы, понять где-какой, чтобы после можно было использовать коннект повторно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2021, 20:17 |
|
||
|
|
start [/forum/topic.php?fid=40&gotonew=1&tid=1559851]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
51ms |
get topic data: |
12ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
2ms |
| others: | 278ms |
| total: | 450ms |
| 0 / 0 |
