powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / fb_lock_print -d при нормальной нагрузке
25 сообщений из 55, страница 2 из 3
fb_lock_print -d при нормальной нагрузке
    #38632456
СИА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Gallemarу меня уже ощущение что стабильно работающая БД это или база в 2-3 гига,которую каждый день ресторят или это мифическое создание,её никто не видел,но все о ней говорят

Обрати внимание на вот это:

Alexey KovyazinМного mutex wait.
Это означает, что приложение разработано таким образом, что постоянно лезет к каким-то ресурсам, получает отлуп и снова лезет.

Например, такого можно добиться, если сделать цикл с условием выхода по времени , внутри которого идет попытка апдейта некой записи, в случае возникновения ошибки она давится, и снова идет попытка апдейта.
Цель такого цикла - пытаться захватить запись на чтение путем холостого апдейта. При длине цикла в 3 сек сервер может сделать тысячи (а то и десятки тысяч) безуспешных апдейтов.


У С-Маркета, если я не ошибаюсь, ноги растут из Мира Торговли, а когда-то давно я имел дело с этим продуктом. И там, опять таки если мне не изменяет склероз, все операции, изменяющие складские регистры, делались как раз вышеописанным образом.
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632465
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
СИА, я насчет Мира торговли уточню. По ответу Ковязина разработчик ответил:

Леонид
ну чего Ковязин говорит - мы такой херней не занимаемся, если только FIB сам, да и то слабо себе представляю зачем и это, да и не идиоты его писали.
Про остальное ничего не могу сказать
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632479
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GallemarС тобой как то можно приватно пообщатьсяМыл вроде и так всем известен. Но чудес не ожидай :)
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632480
СИА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Gallemar, а ты DDL глянь, там подозрительных циклов нету? UDF типа Sleep не подключаются?
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632486
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
СИАGallemar, а ты DDL глянь, там подозрительных циклов нету? UDF типа Sleep не подключаются?
по UDF не подключается,но лучше у разработчика уточнить
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632487
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladGallemarС тобой как то можно приватно пообщатьсяМыл вроде и так всем известен. Но чудес не ожидай :)
Да я и в Деда Мороза давно не верю :)
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632504
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemarмы такой херней не занимаемся
Зато они занимаются хернёй в виде массовых апдейтов 100500 записей. В морг.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632506
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovGallemarмы такой херней не занимаемся
Зато они занимаются хернёй в виде массовых апдейтов 100500 записей. В морг.

Дима,а как ещё реестры по партионке,остаткам и продажам занести? Таблицу удалить и заново заполнить*
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632508
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GallemarС запросами косяк главный в том что это как правило большие отчеты или работа модуля заказов,это очень нагруженные процессы.1) Эти самые "большие отчеты" (да и "работа модуля заказов") - они точно должны работать на том же хосте, что и обычные пользователи ? Их на хост с какой-нить совсем-недавней-копией никак нельзя пересадить ?
2) Планы выполнения и статистика по таблицам этих "больших отчетов" - так и останутся Великой тайной Забайкалья ?
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632510
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
?
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632512
miwaonline
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GallemarDimitry Sibiryakovпропущено...

Зато они занимаются хернёй в виде массовых апдейтов 100500 записей. В морг.

Дима,а как ещё реестры по партионке,остаткам и продажам занести? Таблицу удалить и заново заполнить*
ДС, кстати, уже высказывался на эту тему.
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632513
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miwaonlineGallemarпропущено...

Дима,а как ещё реестры по партионке,остаткам и продажам занести? Таблицу удалить и заново заполнить*
ДС, кстати, уже высказывался на эту тему.
Хы,разработчику покажу
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632517
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидGallemarС запросами косяк главный в том что это как правило большие отчеты или работа модуля заказов,это очень нагруженные процессы.1) Эти самые "большие отчеты" (да и "работа модуля заказов") - они точно должны работать на том же хосте, что и обычные пользователи ? Их на хост с какой-нить совсем-недавней-копией никак нельзя пересадить ?
2) Планы выполнения и статистика по таблицам этих "больших отчетов" - так и останутся Великой тайной Забайкалья ?
1. Частично перенесены в аналитику,но кому то нужны оперативные данные.
2. Нет,поделюсь когда отсортировка по усерам будет. У меня не Забайкалье,а Прибайкалье :)
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632519
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Забайкалье это Чита, чи не та
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632581
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar1. Частично перенесены в аналитику,но кому то нужны оперативные данные.Выскажу ересь, наверное, но: что мешает тебе перенаправить их любопытство с базы-продакшена на... базу-репликант ? Ведь она содержит такие же оперативные данные, с отставанием несколько десятков секунд или пару-тройку минут. Она живёт на другом хосте, к ней лезет только один IBPRepl, он потерпит соседей. И в ней наверняка выключены триггера.
А те, кто запускают "тяжкие отчёты", они ведь ничего не меняют в данных при этом ? (понятно, что в аудите наверняка меняют, типа: "Иванов запустил Супер-пупер Отчёт номер 1" - но это не в счёт).
Gallemar2. Нет,поделюсь когда отсортировка по усерам будет.Дело твоё. Только что даст эта самая "отсортировка по усерам", какую доп. инфу она несёт ?

ЗЫ. Ты просил юзеров о том, чтобы в момент тормозов они показали тебе конкретный режим, который тупит, но который в обычных случаях - летает ? Это ведь и будут первые зацепки. Там наверняка не навороченные "тяжкие запросы", а что-нить типа 3-4 джойнов...
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632596
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,натравлю,только когда продуктив по производительности подтяну. Сейчас ещё 20 усеров подкинули,везде жмет. Ну и один из пересчетов забивает таблицу реплики до неприличия,ищу какой нибудь выход (например выкинуть вообще эти таблицы из пересчетов).
По сортировке - у меня есть 2-3 усера от работы которых многое зависит и за тормоза в работе они дерут три шкуры. Упор на них. Ну и нужен отбор по клиентам,т.к. их просто много (оперативные данные,отчеты,1с,аналитика).
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632597
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemarу меня уже ощущение что стабильно работающая БД это или база в 2-3 гига,которую каждый день ресторят или это мифическое создание,её никто не видел,но все о ней говорятбаза почти 40 гб, ресторилась за последние пару лет 1 раз, меньше сотни коннектов в рабочее время не бывает. тьфу3х работает вполне себе стабильно.

Там ли ты ищешь проблему?
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632601
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Простой пример тормозов - усеры запустили заказы,разнос оплат,20 разных отчетов 100 человек,50 забивает одни документы,ещё 50 - совершенно другие. Тормозит у всех. Что это значит - заказы сформируют на 10 минут позже,отчеты долго выбираются - вместо 5 минут - 10, документ вместо 1 минуты оприходуется 4 минуты. у меня такого что вот кто то запустил что то - и все сидят курят. Обычно базу вешают суммарной работой. Вешают это не значит что база не рабочая,работать становится некомфортно. Ну и чем больше времени проходит от рестора тем ярче это выражено.
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632603
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan_PisarevskyGallemarу меня уже ощущение что стабильно работающая БД это или база в 2-3 гига,которую каждый день ресторят или это мифическое создание,её никто не видел,но все о ней говорятбаза почти 40 гб, ресторилась за последние пару лет 1 раз, меньше сотни коннектов в рабочее время не бывает. тьфу3х работает вполне себе стабильно.

Там ли ты ищешь проблему?
Не знаю
Я могу также показать БД в 15 гигов,не рестореные годами и ничего. ПО тоже самое. Просто разница в усерах - одни колошматят приходы и не парятся,другие функционал используют на 99%. В чем причины падения производительности - я не вижу. Но факт - чем больше усеров и больше БД,тем меньше время от рестора до рестора.
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632611
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemarу меня есть 2-3 усера от работы которых многое зависит и за тормоза в работе они дерут три шкуры. Упор на них.Остановись пока только на них, раз они такие "критичные".

Что именно они делают, только ли запросы или еще и меняют там что-то ?
Надо выдернуть (из трейса, вестимо) 3-4 действия (select'a или DML), которые достаточно часто ими делаются, и которые длятся свыше 1-2 секунд. С конкретными значениями параметров.
Затем:
1) самому запустить их в 10 утра, в 13 и 17 дня, при чём по 3-4 раза в каждый "забег". Записать статистику по каждому запуску.
2) запустить их же, когда начнутся тормоза. Записать статистику.

Так хоть что-то будет, помимо этих таинственных стуков... :-)

ЗЫ. Кста! А натравливал ли ты на свой продакшен такую хорошую утилиточку, как IBAnalyst ? И если да, то что она тебе сказала в своём отчете с рекомендациями ?
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632630
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, и вот еще что.

1. Несмотря на то, что у тебя поднят IBPRepl, у тебя там с еще и с nbackup'ом какая-то возня, так ведь?
Про то, что он шуршит по ВСЕМУ файлу твоей базы в поисках 10 изменённых страниц - ты ведь знаешь, разумеется (это не так только в 3.0).
Запусти какой-нибудь "тяжкий" запрос, выполняемый кем-то из тех троих vip-юзеров, несколько раз до энбекапа. Запиши статистику.
Дальше сделай энбекап и повтори после него этот же запрос. Будет ли разница ? (мну мерешится, что будет, ибо энбекап должен вытеснить из кеша данные, вычитанные туда "тяжким" запросом)

2. Мой продакшен:
::: NB ::: FW = OFF!
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
$ gstat -h prodalias

Database "/var/db/firebird/prodfile.fdb"
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              677908538
        Page size               16384
        ODS version             11.2
        Oldest transaction      653443008
        Oldest active           653443009
        Oldest snapshot         653443009
        Next transaction        653443014
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      24465399
        Implementation ID       24
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        1
        Creation date           Oct 2, 2012 21:45:05

    Variable header data:
        Sweep interval:         0
        *END*
И мой репликант продакшена:
::: NB ::: FW = ON
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
$ gstat -h 192.168.0.61:/u01/db/firebird/production/prodfile.fdb

Database "/u01/db/firebird/production/prodfile.fdb"
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              467700955
        Page size               16384
        ODS version             11.2
        Oldest transaction      446454218
        Oldest active           446454219
        Oldest snapshot         446454219
        Next transaction        446454220
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      21246626
        Implementation ID       24
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        1
        Creation date           Oct 2, 2012 21:45:05
         Attributes              force write 

    Variable header data:
        Sweep interval:         0
        *END*
База репликанта грузится только IBPRepl'ом, так что FW = ON на скорость там влияет мало (если вообще влияет). А вот отключка FW на продакшене - еще как повлияла!
SOS-дока и скрипт для восстановления с базы-репликанта всегда под рукой. Метаданные синхронизятся по расписанию, несколько раз в сутки (переносится всё, за исключением DDL таблиц - это надо врупопашную разруливать; но это и нечасто требуется).
И не говорите мну, что мы тут буратины-камикадзе. В бою проверялось уже раза три или четыре, не помню - ничего, выжили.
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632634
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,Паша,если ты такой злобный буратин то покажи MaxUnflushdWrites и MaxUnflushdWritesTime из конфига.
С FW связываться не хочется, например MySQL в таком режиме пашет по дефолту,там после каждой перезагрузки гемор в виде проверок лезет.
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632639
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GallemarТаблоид,Паша,если ты такой злобный буратин то покажи MaxUnflushdWrites и MaxUnflushdWritesTime из конфига.вот изменённые параметры нашего конфига на продакшене (используется SC):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
$ grep "^[^#;]" firebird.conf | sort
BugcheckAbort = 1
ConnectionTimeout = 90
DefaultDbCachePages = 768
ExternalFileAccess = Restrict /opt/firebird/scripts
LockHashSlots = 25013
LockMemSize = 4194304
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1
TempCacheLimit = 2147483648

GallemarС FW связываться не хочется, например MySQL в таком режиме пашет по дефолту,там после каждой перезагрузки гемор в виде проверок лезет.А причём тут MySQL ?!
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632642
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидGallemarТаблоид,Паша,если ты такой злобный буратин то покажи MaxUnflushdWrites и MaxUnflushdWritesTime из конфига.вот изменённые параметры нашего конфига на продакшене (используется SC):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
$ grep "^[^#;]" firebird.conf | sort
BugcheckAbort = 1
ConnectionTimeout = 90
DefaultDbCachePages = 768
ExternalFileAccess = Restrict /opt/firebird/scripts
LockHashSlots = 25013
LockMemSize = 4194304
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1
TempCacheLimit = 2147483648


MaxUnflushedWrites = -1,MaxUnflushedWriteTime = -1 - минус один это что значит?
LockHashSlots = 25013 - а как же рекомендованые 10007 ? Hash lengths покажи свой.
TempCacheLimit = 2147483648 - зачем так много?
...
Рейтинг: 0 / 0
fb_lock_print -d при нормальной нагрузке
    #38632648
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar> MaxUnflushedWrites = -1,MaxUnflushedWriteTime = -1 - минус один это что значит?

Почему бы не глянуть в описании? Там же ясно написано, что это Disable.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25 сообщений из 55, страница 2 из 3
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / fb_lock_print -d при нормальной нагрузке
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]