Ovchinnikov Vasily wrote: > dimon пишет: > > Симптомы: по top 50% загрузка, > ну, допустим. > > Что за аппарат?
Сервак на Pentium D 1.8. Ядро не SMP. ALT Linux. 2.6.11 kernel. RAID external Promise. RAID5. SCSI Adaptec Ultra Wide сколько там, чип не помню на память. > > Повторю вслед вопросы ДК: > Дистрибутив? Ядро? Диск/диски, IDE/SCSI, конфигурация разделов? > Памяти сколько? > Вывод top не помешал бы с сортировкой по процессорному времени и > информацией о занимаемой памяти. > Выше ответил. Память 1 Гб. Учту про вывод на будущее. > С транзакциями надо разбираться не на 50 одновременно запущенных > приложениях, а на минимально достаточных их комбинациях, делая акцент на > узких местах, которые вам, как разработчикам, все должны быть известны > уже на этапе проектирования системы. > С транзакциями на данный момент проблем нет. Система работала в том момент в обычном режиме. Ничего необычного не запускалась. > > Система в разработке, > > сейчас идет тестирование под > > нагрузкой и некоторый элемент бардака > > таки присутствует, спорить не буду. > Бардак ликвидировать. Все эксперименты надо планировать заранее. > В том то и дело, что именно сейчас еще можно пробовать и эксперементировать. Система не в работе. В крайнем случае - бэкап можно восстановить. > >Что собственно хотел спросить... В логах > > (системных и firebird-а) - 0. По доброму не > > шатдаунится. > Как выполняется такой шатдаун "по-доброму"? Описание в студию! Ну... В моем понимании это service firebird stop, т.е. в конечном итоге fbmgr -shut. > - Кто с базой работает в этот момент и чем занимается ~45-50 клиентов. Все обычно, сутками так и работает. В том то и дело, что было бы что то неординарное, копали бы туда... > - fuser mydatabase.fdb посмотреть и наказать Хорошо, буду иметь это ввиду. Действительно не смотрел. Хотя чисто теоретически должен был работать user firebird. > - мониторить запросы на клиентах > Ну... Можно конечно. Хотя клиенты под Linux, это все таки можно сделать дописав клиентскую часть. > > gstat номера транзакций > > читает и выдает а общую статистику > > -нет. > Как снимается статистика? Полная командная строка какая? gstat -all не выдавал информацию по статистике Index, Data pages и т.д., вообщем ту часть что идет после "Database file sequence". gstat -header запущенный локально выдавал результат как и положено. Номера транзакций при этом не менялись, запускал несколько раз. Разрыв между next и oldest active был 1. Я через isc_database_info с удаленного рабочего места тоже не смог получить ответ от сервера. Там запрашивается isc_info_page_size, _db_size_in_pages, _sweep_interval, _forced_writes, _oldest_transaction, _oldest_active, _oldest_snapshot, _next_transaction. Т.е. создалось впечатление что "клиентская" часть сервера (если так можно сказать) висит. > Смотреть можно и удаленно тем же IBAnalyst, например. > Статистику header page тоже сюда! > > > Ну это, я так понимаю, из за того > > что эту информацию он напрямую читает. > Ну, тут явно причинно-следственная связь нарушена, пропустим... > > > Что еще можно было посмотреть в этой > > ситуации чтобы понять причину "почему > > стоим"? > Что за железо? Конфигурация какая? > Методику тестирования упрощенно бы понять, спектр выполняемых запросов > (маленькие и/или быстрые и/или большие и/или медленные), количество > одновременных коннектов. Стараемся чтобы были маленькие, тяжелых запросов - нет. Ну, т.е. таких что выполняются в течении нескольких 10 секунд с блокировками. Где то до 50 коннектов. > > Что в firebird.conf? Что-то меняли или все по умолчанию? > Увеличили размер DefaultDbCachePages. Больше не припомню...
