iBase.ru Forum

Могу почти с полной увереностью утверждать о несовместимости ядра linux 2.6 и firebird 1.5 и 2.01.

Запускаются 10 и более долгоиграющих запросов, неважно каких, главное выполняющихся долго по времени,

на ядре 2.4
4 500 6099 17944 15 0 95148 24944 schedu S ? 0:21 fb_server
4 500 6145 17944 15 0 88124 19464 schedu S ? 0:02 fb_inet_server
4 500 6355 17944 15 0 80284 13356 schedu S ? 0:00 fb_inet_server
4 500 6370 17944 15 0 96876 26472 schedu S ? 0:27 fb_inet_server
4 500 6899 17944 18 0 90408 21684 schedu S ? 0:39 fb_inet_server
4 500 8113 17944 15 0 90428 20476 schedu S ? 0:01 fb_inet_server
0 500 8409 8154 15 0 3908 644 pipe_w S pts/3 0:00 grep fb_
-bash-2.05b$

как видно, управлением приоритетов занимается нормальный шедулер, который долгоиграющим процессам понижает приоритет, а коротким транзакциям повышает, эффект - нормальный, отчеты считаются как смогут, а на запись и короткое чтение выполняется мгновенно
-bash-2.05b$ top
11:19:41 up 22 days, 16:12, 3 users, load average: 5,72, 3,74, 2,66
246 processes: 240 sleeping, 6 running, 0 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait idle
total 71,6% 0,0% 8,1% 0,0% 1,2% 18,7% 0,1%
cpu00 65,1% 0,0% 8,9% 0,0% 3,1% 22,7% 0,0%
cpu01 77,8% 0,0% 9,1% 0,0% 1,3% 11,1% 0,3%
cpu02 70,3% 0,0% 6,7% 0,0% 0,1% 22,5% 0,1%
cpu03 73,4% 0,0% 7,5% 0,0% 0,3% 18,5% 0,0%

процессоры загружены на 100%, так что все ок

на ядре 2.6
4 84 9744 2303 15 0 115300 12788 semtim Ss ? 0:38 fb_inet_server
4 84 9766 2303 15 0 115300 12788 - Rs ? 0:39 fb_inet_server
4 84 9767 2303 15 0 115296 12784 - Rs ? 0:39 fb_inet_server
4 84 9768 2303 15 0 115296 12784 - Rs ? 0:39 fb_inet_server
4 84 9769 2303 15 0 115304 12792 semtim Ss ? 0:39 fb_inet_server
4 84 9771 2303 15 0 115296 12784 - Rs ? 0:39 fb_inet_server
4 84 9772 2303 15 0 115304 12788 semtim Ss ? 0:39 fb_inet_server
4 84 9773 2303 15 0 115300 12788 semtim Ss ? 0:38 fb_inet_server
4 84 9774 2303 15 0 115296 12784 semtim Ss ? 0:39 fb_inet_server
0 0 9788 9745 18 0 57068 712 - S+ pts/4 0:00 grep fb_
[root@ibserverhp ~]#

процессы все, кроме четырех(4 процессора), заслипованы функцией semtimedop и приоритеты у всех однаково большие
[root@ibserverhp ~]# top
top - 11:35:52 up 21:17, 5 users, load average: 3.58, 3.46, 2.60
Tasks: 137 total, 3 running, 134 sleeping, 0 stopped, 0 zombie
Cpu(s): 50.2% us, 6.8% sy, 0.0% ni, 42.0% id, 0.7% wa, 0.0% hi, 0.4% si
Mem: 8161276k total, 8127836k used, 33440k free, 79620k buffers
Swap: 10241428k total, 128k used, 10241300k free, 7516560k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9767 firebird 15 0 112m 12m 3340 S 25 0.2 5:10.90 fb_inet_server
9769 firebird 15 0 112m 12m 3340 R 26 0.2 5:10.98 fb_inet_server
9744 firebird 15 0 112m 12m 3340 S 27 0.2 5:05.18 fb_inet_server
9768 firebird 15 0 112m 12m 3340 S 25 0.2 5:09.09 fb_inet_server
9771 firebird 15 0 112m 12m 3340 S 25 0.2 5:09.78 fb_inet_server
9772 firebird 15 0 112m 12m 3340 S 25 0.2 5:11.14 fb_inet_server
9774 firebird 15 0 112m 12m 3340 R 26 0.2 5:11.22 fb_inet_server
9766 firebird 15 0 112m 12m 3340 S 25 0.2 5:07.45 fb_inet_server
9773 firebird 15 0 112m 12m 3340 S 25 0.2 5:05.25 fb_inet_server

процессоры заняты на 60%, система в ступоре, проверено и на 32 разрядной и на 64 разрядной платформе.

С уважением barsuk mbbnk@mail.ru

теперь коммент по делу. Например винды не регулируют приоритеты для классика, и ничего страшного не происходит.
Руление приоритетами процессов для классика как известно чревато ухудшением производительности из-за блокировок, по крайней мере теорически. Именно поэтому в сервере не дается возможность определять приоритеты для конкретного процесса в классике.

Поведение же шедулеров 2.6 известно, и даже вроде бы не является проблемой только в отношении FB, а является проблемой вообще.

http://www.sql.ru/forum/actualthread.as ... 05501&pg=3

Почему система впадает в ступор, если приоритеты для всех процессов классика равны - я не понимаю. Линукс - г..но?

Если это известный факт, почему про это ни где фактически не написано, например
дистрибутив for linux 2.4
месяц грохнули на эту проблему

проблема-ведь выявилась при реальной работе. я не знаю, возможно-ли такое увидеть в тестах.
И потом, надо чтобы у такой системы был админ, способный разобраться в источнике проблемы, например как Вы.

Собственно, если FB сразу ставился на ядро 2.6, тогда понятно, что обнаружить источник проблемы сложновато. А если делался апгрейд с 2.4, то тут извините, и коню ясно - до апгрейда было хорошо, после - плохо. Что меняли? ядро.

Поставит человек firebird (на 2.6). Начнет его тестить и сравнивать с oracle, mysql с не дай бог ms sql и сделает неправильные выводы.
Или как у нас купили шелезяку круть, поставили 64х linux. поставили FB2 и ... приплыли.

исходя из обнаруженного поведения лично я не вижу проблемы в Firebird. Firebird, как я уже сказал, не занимается управлением приоритетами собственных процессов. Это задача операционки.
И если проблема выглядит именно таким образом, то она проявится однозначно на ЛЮБОМ ДРУГОМ софте имеющем "классическую" архитектуру, т.е. в виде множества одинаковых конкурирующих процессов.
Так что про "сравнивать с..." - не надо.

В том то и дело, что когда стали про sheduler 2.6 искать везде только -
супер пупер планировщик писаный - переписанный, опитимизированный - переоптимизированный,
тогда возникает вопрос, все дело в волшебных пузырьках firebird получается
а вы пишете типа - ситуция давно известна.
Может кто из линуксоидов что скажет?

тогда возникает вопрос, все дело в волшебных пузырьках firebird получается

так вот никак не получается. я еще раз подчеркиваю, что на виндах приоритеты у процессов классика операционка не меняет. И СУБД вообще не виновата, что ее процессам операционная система сначала выставляла приоритеты так, а потом сяк.
Классик вообще подразумевает нормальную работу при одинаковых приоритетах своих процессов. Нет у процессов классика никаких "долгих транзакций" и прочей ... мути, извините за выражение. И даже если одни процессы классика что-то усиленно делают, а другие ничего не делают, то какой вообще может быть выгода от снижения приоритета НЕРАБОТАЮЩЕМУ процессу?

Я тоже согласен, что стоит выслушать линуксоидов, ибо муть какая-то получается, извините, с этим планировщиком. это получается, что новый шедулер не в состоянии нормально процессор между процессами разделять?

Узнавал у знакомого ораклиста
Говорит на 2.6 нормально 10 оракл рулит, загрузка покруче нашего, железо не особо. сказал, что в оракле можно повлиять на шедулер, как в любой нормальной СУБД, что оин и сделали.

orache shared, dedicated?

в оракле можно повлиять на шедулер, как в любой нормальной СУБД, что оин и сделали.

рискну предположить, что это есть полная ахинея. я еще раз повторяю что FB никак не управляет шедулером и это ему вообще не нужно. Разделение процессорного времени между процессами - это сугубо дело в операционке.
Если оракл использовался shared, то тогда никаких проблем у него, как и у FB SuperServer, с шедулером ОС нет и быть не может.

кто-то из нас чего-то не понимает.

в первом письме ветки в приведенной статитистике не вижу fb_lock_mgr. А от него многое зависит в данном случае.

кстати. я совсем забыл. если его планировщик задвинул по приоритету...

kdv писал(а):кстати. я совсем забыл. если его планировщик задвинул по приоритету...

именно. Его активно бомбят куча процессов, шедулер понижает ему приоритет и все виснет, как раз на семафорах. У Пешкова это воспроизвелось начиная с 50-70 нагруженных коннектов. Но на ядре 2.4 он сейчас проверить не может...

4 84 2516 2309 18 0 33856 14396 sync_p Ds ? 0:40 fb_inet_server
4 0 2518 0 15 0 10460 1316 semtim S ? 0:00 /usr/local/firebird/bin/fb_lock_mgr
4 84 2520 2309 18 0 33856 14392 sync_p Ds ? 0:35 fb_inet_server
4 84 2522 2309 25 0 33856 14396 - Rs ? 0:37 fb_inet_server
4 84 2523 2309 25 0 33852 14392 - Rs ? 0:30 fb_inet_server

Ещё работает

4 84 2537 2306 15 0 33852 14444 - Rs ? 2:32 fb_inet_server
4 0 2539 0 15 0 10460 1352 semtim S ? 0:00 /usr/local/firebird/bin/fb_lock_mgr
4 84 2541 2306 15 0 33856 14448 semtim Ss ? 2:35 fb_inet_server
4 84 2542 2306 15 0 33856 14448 - Rs ? 2:34 fb_inet_server
4 84 2544 2306 15 0 33856 14448 semtim Ss ? 2:28 fb_inet_server
4 84 2546 2306 15 0 33852 14448 semtim Ss ? 2:12 fb_inet_server
4 84 2548 2306 15 0 33852 14444 semtim Ss ? 1:33 fb_inet_server
4 84 2550 2306 15 0 33856 14448 semtim Ss ? 0:59 fb_inet_server
4 84 2553 2306 15 0 33852 14448 semtim Ss ? 1:02 fb_inet_server
4 84 2555 2306 15 0 33856 14448 semtim Ss ? 1:10 fb_inet_server
4 84 2558 2306 15 0 33856 14452 semtim Ss ? 1:12 fb_inet_server

Уже тормозит.

Нивкоем влучае не пытаемся свалить всё на firebird, просто пытаемся с помощью квалифицированных специалистов(вас) разобраться в проблемме.

рискну предположить, что это есть полная ахинея. я еще раз повторяю что FB никак не управляет шедулером и это ему вообще не нужно. Разделение процессорного времени между процессами - это сугубо дело в операционке.

Я думаю Scheduler принимает решение о смене приоритета на основе многих факторов: интенсивность доступа к дискам, потребление оперативки, загрузка CPU....а firebird этими факторами может непосредственно манипулировать, возможно с помощью fb_lock_mgr(могу ошибаться), поэтому возникло подозрение что МЫ чтото упустили в настройках firebird.

Готовы принять любой совет, оборудование для тестировая есть, возможность воспроизводить нагрузки тоже. Со своей стороны денно и ночно, с перерывами на обед,мучаем scheduler ядра. Тестировалось запросом на чтение, БД 30г.

dimitr писал(а):

kdv писал(а):кстати. я совсем забыл. если его планировщик задвинул по приоритету...

именно. Его активно бомбят куча процессов, шедулер понижает ему приоритет и все виснет, как раз на семафорах. У Пешкова это воспроизвелось начиная с 50-70 нагруженных коннектов. Но на ядре 2.4 он сейчас проверить не может...

Я как то пропустил это дело для 2.1 через отладчик (тоже имели место зависоны, но другой природы) и мне показалось, что fb_lock_manager используется только если fb_inet_server сам не может выполнить блокировку, например из-за отсутствия прав. В остальных случаях fb_inet_server-а бомбили друг друга (сигналами LockSignal из firebird.conf) и соврешенно игнорировали fb_lock_manager-а. Поэтому, если я прав, версия о задвинутом менеджере блокировок имеет смысл только если конекты осуществлены от разных пользователей.

Хотя.. Может я что-то недопонял или есть ньюансы?

Согласен с предыдущим оратором, последил за fb_lock_mgr, он почемуто всё время в слипе(следил за ним strace). fb_inet_server без его помощи могут блокировки распределять? или это должна делать корректно система?
Вот что почерпнули из описалова ветки 2.6 (http://www.opennet.ru/base/sys/linux26_intro.txt.html)

Другим изменением, позволившим Линуксу стать более интерактивной ОС в
отношении приложений, поддерживающих такую интерактивность, стала
поддержка новых "futexes" (или "Fast User-Space Mutexes" - быстрые
семафоры пользовательского пространства). Futexes - это возможность, с
помощью которой множественные процессы и нити могут выстраивать
последовательность событий так, что они не будут наступать друг другу
на пятки (<<состояние гонки>>). В отличие от традиционных операций
взаимоисключения, поддерживаемых большинством библиотек
распараллеливания процессов, данный способ частично базируется на
поддержке ядра (но только в случае возникновения разногласий) и он
также поддерживает систему приоритетов, позволяющую приложениям или
нитям с более высоким приоритетом, получить первоочередной доступ к
запрошенным ресурсам. Программное определение приоритета задач,
позволило получить более интерактивную систему, что может быть очень
важно в критичных ко времени приложениях.

Изменение параметра LockAcquireSpins = в firebird.conf дало интересные результаты.
в starce процесса fb_inet_server появились долгожданные ошибки:

rt_sigprocmask(SIG_SETMASK, [], NULL, = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], = 0
lseek(3, 6728269824, SEEK_SET) = 6728269824
read(3, "\5\00290\1\0\0\0\0\0\0\0\0\0\0\0\334\6\0\0i\1/\0p\37\215"..., 8192) = 8192
rt_sigprocmask(SIG_SETMASK, [], NULL, = 0
semop(32768, 0x7fffeec85560, 1) = -1 EAGAIN (Resource temporarily unavailable)
semop(32768, 0x7fffeec85560, 1) = -1 EAGAIN (Resource temporarily unavailable)

Сталкивался ктонито? продолжаем рыть...

Lyas писал(а):Изменение параметра LockAcquireSpins = в firebird.conf дало интересные результаты.
в starce процесса fb_inet_server появились долгожданные ошибки:

rt_sigprocmask(SIG_SETMASK, [], NULL, = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], = 0
lseek(3, 6728269824, SEEK_SET) = 6728269824
read(3, "\5\00290\1\0\0\0\0\0\0\0\0\0\0\0\334\6\0\0i\1/\0p\37\215"..., 8192) = 8192
rt_sigprocmask(SIG_SETMASK, [], NULL, = 0
semop(32768, 0x7fffeec85560, 1) = -1 EAGAIN (Resource temporarily unavailable)
semop(32768, 0x7fffeec85560, 1) = -1 EAGAIN (Resource temporarily unavailable)

Сталкивался ктонито? продолжаем рыть...

Я не сталиквался, но из описания этого параметра из firebird.conf следует что это просто число попыток заблокировать семафор. Когда этот параметр не равен 0, то к семафору применяется операция -1 и к флагам добавляется параметр IPC_NOWAIT. То есть если семафор равен 0 (уже заблокирован), то функция semop вернет -1 и установит errno в EAGAIN - и так или LockAcquireSpins раз или пока семафор не станет положительным. Когда же LockAcquireSpins=0, то параметр IPC_NOWAIT не используется и semop будет "висеть", пока значение семафора не станет положительным. Так что все естественно и объяснимо.

Тогда странно, изменение этого параметра на ядре 2.4 не дало такихже ошибок...

Lyas писал(а):Тогда странно, изменение этого параметра на ядре 2.4 не дало такихже ошибок...

А что тут странного? Как уже выше было сказано, виснет именно на семафорах и именно в 2.6... Ошибка EAGAIN означает, что если бы не ненулевой LockAcquireSpins, то вместо ошибки имело бы место зависание.