Могу почти с полной увереностью утверждать о несовместимости ядра 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
Несовместимость linux 2.6 и firebird
Модераторы: kdv, Alexey Kovyazin
Несовместимость linux 2.6 и firebird
Последний раз редактировалось barsuk 12 апр 2007, 14:39, всего редактировалось 1 раз.
теперь коммент по делу. Например винды не регулируют приоритеты для классика, и ничего страшного не происходит.
Руление приоритетами процессов для классика как известно чревато ухудшением производительности из-за блокировок, по крайней мере теорически. Именно поэтому в сервере не дается возможность определять приоритеты для конкретного процесса в классике.
Поведение же шедулеров 2.6 известно, и даже вроде бы не является проблемой только в отношении FB, а является проблемой вообще.
http://www.sql.ru/forum/actualthread.as ... 05501&pg=3
Почему система впадает в ступор, если приоритеты для всех процессов классика равны - я не понимаю. Линукс - г..но?
Руление приоритетами процессов для классика как известно чревато ухудшением производительности из-за блокировок, по крайней мере теорически. Именно поэтому в сервере не дается возможность определять приоритеты для конкретного процесса в классике.
Поведение же шедулеров 2.6 известно, и даже вроде бы не является проблемой только в отношении FB, а является проблемой вообще.
http://www.sql.ru/forum/actualthread.as ... 05501&pg=3
Почему система впадает в ступор, если приоритеты для всех процессов классика равны - я не понимаю. Линукс - г..но?
Почему тогда все молчат
Если это известный факт, почему про это ни где фактически не написано, например
дистрибутив for linux 2.4
месяц грохнули на эту проблему
дистрибутив for linux 2.4
месяц грохнули на эту проблему
проблема-ведь выявилась при реальной работе. я не знаю, возможно-ли такое увидеть в тестах.
И потом, надо чтобы у такой системы был админ, способный разобраться в источнике проблемы, например как Вы.
Собственно, если FB сразу ставился на ядро 2.6, тогда понятно, что обнаружить источник проблемы сложновато. А если делался апгрейд с 2.4, то тут извините, и коню ясно - до апгрейда было хорошо, после - плохо. Что меняли? ядро.
И потом, надо чтобы у такой системы был админ, способный разобраться в источнике проблемы, например как Вы.
Собственно, если FB сразу ставился на ядро 2.6, тогда понятно, что обнаружить источник проблемы сложновато. А если делался апгрейд с 2.4, то тут извините, и коню ясно - до апгрейда было хорошо, после - плохо. Что меняли? ядро.
За fb обидно.
Поставит человек firebird (на 2.6). Начнет его тестить и сравнивать с oracle, mysql с не дай бог ms sql и сделает неправильные выводы.
Или как у нас купили шелезяку круть, поставили 64х linux. поставили FB2 и ... приплыли.
Или как у нас купили шелезяку круть, поставили 64х linux. поставили FB2 и ... приплыли.
исходя из обнаруженного поведения лично я не вижу проблемы в Firebird. Firebird, как я уже сказал, не занимается управлением приоритетами собственных процессов. Это задача операционки.
И если проблема выглядит именно таким образом, то она проявится однозначно на ЛЮБОМ ДРУГОМ софте имеющем "классическую" архитектуру, т.е. в виде множества одинаковых конкурирующих процессов.
Так что про "сравнивать с..." - не надо.
И если проблема выглядит именно таким образом, то она проявится однозначно на ЛЮБОМ ДРУГОМ софте имеющем "классическую" архитектуру, т.е. в виде множества одинаковых конкурирующих процессов.
Так что про "сравнивать с..." - не надо.
Про linux 2.6 везде только похвалы
В том то и дело, что когда стали про sheduler 2.6 искать везде только -
супер пупер планировщик писаный - переписанный, опитимизированный - переоптимизированный,
тогда возникает вопрос, все дело в волшебных пузырьках firebird получается
а вы пишете типа - ситуция давно известна.
Может кто из линуксоидов что скажет?
супер пупер планировщик писаный - переписанный, опитимизированный - переоптимизированный,
тогда возникает вопрос, все дело в волшебных пузырьках firebird получается
а вы пишете типа - ситуция давно известна.
Может кто из линуксоидов что скажет?
так вот никак не получается. я еще раз подчеркиваю, что на виндах приоритеты у процессов классика операционка не меняет. И СУБД вообще не виновата, что ее процессам операционная система сначала выставляла приоритеты так, а потом сяк.тогда возникает вопрос, все дело в волшебных пузырьках firebird получается
Классик вообще подразумевает нормальную работу при одинаковых приоритетах своих процессов. Нет у процессов классика никаких "долгих транзакций" и прочей ... мути, извините за выражение. И даже если одни процессы классика что-то усиленно делают, а другие ничего не делают, то какой вообще может быть выгода от снижения приоритета НЕРАБОТАЮЩЕМУ процессу?
Я тоже согласен, что стоит выслушать линуксоидов, ибо муть какая-то получается, извините, с этим планировщиком. это получается, что новый шедулер не в состоянии нормально процессор между процессами разделять?
а как же оракл
Узнавал у знакомого ораклиста
Говорит на 2.6 нормально 10 оракл рулит, загрузка покруче нашего, железо не особо. сказал, что в оракле можно повлиять на шедулер, как в любой нормальной СУБД, что оин и сделали.
Говорит на 2.6 нормально 10 оракл рулит, загрузка покруче нашего, железо не особо. сказал, что в оракле можно повлиять на шедулер, как в любой нормальной СУБД, что оин и сделали.
orache shared, dedicated?
Если оракл использовался shared, то тогда никаких проблем у него, как и у FB SuperServer, с шедулером ОС нет и быть не может.
кто-то из нас чего-то не понимает.
рискну предположить, что это есть полная ахинея. я еще раз повторяю что FB никак не управляет шедулером и это ему вообще не нужно. Разделение процессорного времени между процессами - это сугубо дело в операционке.в оракле можно повлиять на шедулер, как в любой нормальной СУБД, что оин и сделали.
Если оракл использовался shared, то тогда никаких проблем у него, как и у FB SuperServer, с шедулером ОС нет и быть не может.
кто-то из нас чего-то не понимает.
именно. Его активно бомбят куча процессов, шедулер понижает ему приоритет и все виснет, как раз на семафорах. У Пешкова это воспроизвелось начиная с 50-70 нагруженных коннектов. Но на ядре 2.4 он сейчас проверить не может...kdv писал(а):кстати. я совсем забыл. если его планировщик задвинул по приоритету...
Ещё работает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, просто пытаемся с помощью квалифицированных специалистов(вас) разобраться в проблемме.
Я думаю Scheduler принимает решение о смене приоритета на основе многих факторов: интенсивность доступа к дискам, потребление оперативки, загрузка CPU....а firebird этими факторами может непосредственно манипулировать, возможно с помощью fb_lock_mgr(могу ошибаться), поэтому возникло подозрение что МЫ чтото упустили в настройках firebird.рискну предположить, что это есть полная ахинея. я еще раз повторяю что FB никак не управляет шедулером и это ему вообще не нужно. Разделение процессорного времени между процессами - это сугубо дело в операционке.
Готовы принять любой совет, оборудование для тестировая есть, возможность воспроизводить нагрузки тоже. Со своей стороны денно и ночно, с перерывами на обед,мучаем scheduler ядра. Тестировалось запросом на чтение, БД 30г.
dimitr писал(а):именно. Его активно бомбят куча процессов, шедулер понижает ему приоритет и все виснет, как раз на семафорах. У Пешкова это воспроизвелось начиная с 50-70 нагруженных коннектов. Но на ядре 2.4 он сейчас проверить не может...kdv писал(а):кстати. я совсем забыл. если его планировщик задвинул по приоритету...
Я как то пропустил это дело для 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)
Вот что почерпнули из описалова ветки 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 появились долгожданные ошибки:
в starce процесса fb_inet_server появились долгожданные ошибки:
Сталкивался ктонито? продолжаем рыть...rt_sigprocmask(SIG_SETMASK, [], NULL,= 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [],
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,
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 будет "висеть", пока значение семафора не станет положительным. Так что все естественно и объяснимо.Lyas писал(а):Изменение параметра LockAcquireSpins = в firebird.conf дало интересные результаты.
в starce процесса fb_inet_server появились долгожданные ошибки:
Сталкивался ктонито? продолжаем рыть...rt_sigprocmask(SIG_SETMASK, [], NULL,
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [],
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,
semop(32768, 0x7fffeec85560, 1) = -1 EAGAIN (Resource temporarily unavailable)
semop(32768, 0x7fffeec85560, 1) = -1 EAGAIN (Resource temporarily unavailable)