У одного юзера долго выполняются пишущие транзакции в firebird Superserver, версия 2.5.3.26778-0_Win32.
На тесте — простая запись в таблицу без индекса, с 4 полями (2 string, 2 integer), в отдельной
транзакции занимает примерно 160-200 мс. При этом у нас на тестовых
компах это занимает не более 5-16 мс на той же базе (даже файл тот же, с тем же конфигом).
Ставили мониторы производительности всякие, типа Sinatica Monitor — там увидели, что
запись на диск у юзера субдом идет на скорости не более 0,2 Мб/с. В мониторе ресурсов Win у процесса fbserver.exe такая же скорость записи показывается.
Тогда как у нас — не менее 2,5 Мб/с
Конфиг базы дефолтовый. Соединение с БД через loopback, клиент на том же хосте.
Сервер у юзера новый, довольно мощный: 8 Процессоров по 2 ядра, ОЗУ 16Гб оперативки, Raid массивы на 2 Тб. Win2008 64 бит.
На более слабом компе у него до этого работало намного быстрее. Единственное отличие от наших компов — у юзера диски в RAIDе.
Куда копать, что смотреть, настраивать? Всю голову уже сломали...
Может быть попробовать настроить БД так, чтобы она пореже вызывала операцию flush для диска? Предполагаю, что при каждой вставке записи ваш сервер ждёт, пока все диски в рейде запишут данные и вернут статус о готовности. Это хорошо с точки зрения надёжности, но в реальности избыточно, рейд просто так не дохнет, ему такие гарантии ни к чему.
Здравствуйте, vsb, Вы писали:
vsb>Может быть попробовать настроить БД так, чтобы она пореже вызывала операцию flush для диска? Предполагаю, что при каждой вставке записи ваш сервер ждёт, пока все диски в рейде запишут данные и вернут статус о готовности. Это хорошо с точки зрения надёжности, но в реальности избыточно, рейд просто так не дохнет, ему такие гарантии ни к чему.
Здравствуйте, Alexio, Вы писали:
vsb>>Может быть попробовать настроить БД так, чтобы она пореже вызывала операцию flush для диска? Предполагаю, что при каждой вставке записи ваш сервер ждёт, пока все диски в рейде запишут данные и вернут статус о готовности. Это хорошо с точки зрения надёжности, но в реальности избыточно, рейд просто так не дохнет, ему такие гарантии ни к чему.
A>Какие параметры в firebird.conf трогать?
Вроде они называют это forced writes. Отключается так:
Здравствуйте, vsb, Вы писали:
vsb>Вроде они называют это forced writes. Отключается так:
vsb>gfix -user SYSDBA -password masterkey dbserver:/db/mydb.fdb -write async
vsb>http://www.firebirdsql.org/manual/qsg2-safety.html тут грозят всеми карами небесными за такое на Windows. Имейте в виду.
Да, про этот прием знаю. Думал, что можно без отключения совсем как-то сделать. Типа параметров
#MaxUnflushedWriteTime = 5
#MaxUnflushedWrites = 100
Здравствуйте, Alexio, Вы писали:
A>Да, про этот прием знаю. Думал, что можно без отключения совсем как-то сделать. Типа параметров A>#MaxUnflushedWriteTime = 5 A>#MaxUnflushedWrites = 100
Отключение не отключает записи ВООБЩЕ. Оно просто записи собирает группами и потом выполняет. Эти параметры как раз и отвечают за то, как часто эти записи будут выполняться. Вот отключите forced writes и будут эти параметры действовать, уже ими можете покрутить нужный вам уровень надёжности.
Здравствуйте, Alexio, Вы писали:
A>Куда копать, что смотреть, настраивать? Всю голову уже сломали...
Тут надо выбирать: либо медленно и надёжно, либо быстро, но на свой страх и риск. Как тут уже сообщали, надо включить кэширование записи для конкретной базы и тогда всё заработает возможно на порядок быстрее. Но при первом же аварийном отключении питания компа (без завершения работы ОС) скорее всего ты получишь попорченную базу.
Здравствуйте, ArtDenis, Вы писали:
AD>Тут надо выбирать: либо медленно и надёжно, либо быстро, но на свой страх и риск. Как тут уже сообщали, надо включить кэширование записи для конкретной базы и тогда всё заработает возможно на порядок быстрее. Но при первом же аварийном отключении питания компа (без завершения работы ОС) скорее всего ты получишь попорченную базу.
Попорченную совсем или просто без тех данных, которые в кеше были? Мне не страшно потерять те данные, которые постоянно и часто пишутся. А вот поломать базу, чтобы потом её фиксить пришлось, не хочется очень.
Здравствуйте, Alexio, Вы писали:
A>Попорченную совсем или просто без тех данных, которые в кеше были? Мне не страшно потерять те данные, которые постоянно и часто пишутся. А вот поломать базу, чтобы потом её фиксить пришлось, не хочется очень.
Именно попорченную, для которой надо будет обязательно запускать средство для исправления, чтобы можно было продолжить с ней работать.
Юзер напряг своего админа и выяснилось: RAID аппаратный, уровня 5. Нифига не настраивался. Произвели "какие-то" настройки, включили в ОС кеширование и всё зашуршало. Конфиг базы, видимо, не трогали.
Ну вот, а мы в поисках проблемы половину запросов в программе оптимизировали... Ну, лишним не будет.
Здравствуйте, Alexio, Вы писали:
A>Юзер напряг своего админа и выяснилось: RAID аппаратный, уровня 5. Нифига не настраивался. Произвели "какие-то" настройки, включили в ОС кеширование и всё зашуршало. Конфиг базы, видимо, не трогали. A>Ну вот, а мы в поисках проблемы половину запросов в программе оптимизировали... Ну, лишним не будет.
Вообще, вопросы по настройке железа и оптимизации запросов файрбёрда лучше задавать напрямую разработчикам на этом форуме: http://www.sql.ru/forum/interbase. Они отвечают очень быстро и по делу.
