Привет. В декабре 2008 описывал проблему падения производительности сервера, на которую нарвался когда увеличил DefaultDbCachePages с 75 до 1024 (страница 4 кб ). Firebird CS 2.0.5 + Open Suse Linux (10 или 11 версии), 15 клиентских коннектов, Сервер с 2 GB RAM. База данных всего 3Gb, только что восстановленная из копии.
Тогда мне никто не поверил, но в феврале удалось выяснить, откуда растут ноги. После изменения параметра, простые запросы, не затрагивающие большой объем информации на диске проходили быстрее, чем при установленном по умолчанию значении параметра, а вот те что требовали считывания большого объема информации приводили к тому что все остальные клиенты отдыхали до тех пор, пока этот запрос не завершался, да и они сами проходили гораздо медленнее. Создание резервной копии базы (когда gbak пробегает по всему файлу) или обычное копирование файла (командой cp) превышающего по размеру объем RAM так же тормозило систему. Столкнувшись ещё на двух серверах с подобным падением скорости (в одном случае проблему сделали менее заметной, выполнив перебэкап базы, которую никто не восстанавливал больше года (мусора в ней не было, а вот таблицы наверняка были сильно фрагментированы), в другом нарастили мощность системы ввода-вывода и размер RAM). Провели несколько тестов, сравнили с данными полученными на давно уже работающих серверах под управлением старых версий Linux с ядрами 2.4 и поговорив с одним знакомым специалистом из Novell выяснили следующее. 1.В ядрах Linux, начиная с версий 2.6 при работе с большими файлами (чтение, копирование, запись) загрузка процессора 100%, при этом в top видно что не процесс работы с файлом занимает столько ресурсов, а ожидание ввода- вывода (Wait). и пока читается или копируется большой файл - все ждут, именно ВСЕ. 2.Проблема проявляется на всех типах файловых систем на всех интерфейсах накопителей SATA, SAS, SCSI, USB-Drive. 3. По словам специалиста из Novell в Oracle как то это порешали, никто ни разу не жаловался на такие проблемы при работе с Oracle а SLES (SUSE Linux Enterprise Server) для серверов с Oracle используется часто (в Интернете массовые жалобы на эту проблему при работе бэкапа больших баз MySQL) 4. На настоящий момент проблема не решена разработчиками ядра Запустили в Google запрос такого вида "загрузка процессора при копировании больших файлов ядро 2.6" оказалось что народ массово воет в форумах всех издателей дистрибутивов, от того что при копировании больших файлов практически стоит ступором и не работает GUI, чего никогда не было на ядрах 2.4 нашли в трекере ядра такую запись http://bugzilla.kernel.org/show_bug.cgi?id=7372 и об этом же через два года http://bugzilla.kernel.org/show_bug.cgi?id=12309 Ну и как вывод. Проблему которую поймали, увеличивая DbCache - упреждающее чтение увеличило нагрузку на дисковую подсистему, это увеличение оказалось для данного сервера критическим - система стала тормозить. Уменьшили кэш - стало работать приемлемо. Думаю, что это не связано с устареванием кэша, так как проявляется и при одном коннекте к базе, а только с увеличением чтений с диска Остановились на 256 страницах. Теперь думаю о том какую OS ставить на сервера заказчикам, которые решат поменять серверы, установленные 5 лет назад. С уважением, Мещеряков Вадим директор ООО Комплексные Системы. 454021 г. Челябинск ул. 40 лет Победы 31, 77 Тел: +7 (351) 2807917 Web: www.del-fin.ru
