Traygod,

слушайте, ну стыдоба же. база 772 мб, 10 пользователей, 14 тысяч транзакций за 4 дня, и какие-то там тормоза? У вас 1С и MS SQL на этом же компе все сжирают, для Firebird ничего не остается, потому он и тормозит.

Traygodставил эксперименты по переносу на отдельный сервак firebird быстрее не работал
не верю.

GallemarМне вот интересно,если sweep выключить изменения будут? может просто ПО транзакций намолотит и sweep стартует?
разуй глаза - у него за 4 дня 10 человек намолотили 14 тысяч транзакций. Какой вообще sweep? :-)

кстати, я пропустил еще момент, прямо для "пятницы".
Автор пишет, что конфиг фб по умолчанию, т.е. параметры не менялись, при этом он прикладывает конфиг. Зачем, если У ВСЕХ, кто не менял конфиг, он точно такой же? :-)

Ну и, автору - выносите FB на отдельный компьютер, там уже можно разбираться. На той свалке, куда вы засунули Firebird, диагностировать что-то не имеет смысла, вообще, т.к. просто будет констатация какого-либо факта вроде "1с сожрал диск", "ms sql съел всю память". Причем, констатация будет риторическая, потому что "отобрать диск и память" не получится. Разве только если вместо дисков воткнуть RAID 10 из 8-ми SSQ, а памяти добить до 128гиг.

AriochVirtusalBox ? Hyper-V ? (это про память)
не хотел я влезать, но давайте посмотрим:
- виртуалка это кусок памяти, со своими ресурсами, да.

- я не припомню, чтобы виртуалке жестко выделялись такие ресурсы, как ядра и память. То есть, если приложение в хост-ОС заняло всю память, и жрет процессоры, то виртуалка выпадет в своп и будет биться за те же ядра.
Реально поделить эти ресурсы можно разве что в хост-виртуалке (гипервизоре), типа VSphere ESXi.

- виртуалка всегда хуже хост-ОС по диску, по определению. А СУБД это работа с диском. Даже если взять совсем ненагруженную машину, и в ней в виртуалке запустить ФБ, он будет медленнее даже в однопользовательской работе, чем будучи запущеным напрямую в хост-ОС.

ну и наконец, я не очень понимаю, почему есть надежды на виртуалку. Она же в любом случае ресурсов (как минимум памяти) потребляет куда больше, чем сам ФБ.

AriochА вот насчет вируталки...
ок, это хорошо. Но причина торможения неясна, может это и не память. В отношении памяти, cpu и io очень легко делается снимок для анализа в ProcessExplorer, после чего он анализируется в Excel.
У меня на памяти анализ одного терминального сервера с ФБ за рубежом. Выяснилось, что приложения в терминальных сессиях просто пожирают всю память (а ее там много было), да еще и с диском было плохо, то ли антивирус, то ли еще какая-то софтина через себя IO пропускала. Разумеется, вариант был один - вынести СУБД на выделенную машину.

p.s. риторически: меня уже давно не покидает ощущение, что при таких оптимизациях я рассказываю какие-то запредельно нудные банальности. Но до которых админы этих систем почему то не доходят, совершенно. Либо просто не умеют пользоваться средствами мониторинга, либо имеют слабое представление о функционировании железа и ОС. А может и то и другое вместе :-)

Arioch,

не могу - это была платная оптимизация :-)
С одной стороны, да, хорошо увековечивать опыт в статьях, с другой стороны, кто их читает? :-)
Ну и, "Оптимизация Firebird" к Firebird с точки зрения настройки конфига относится только процентов на 30, в лучшем случае. Остальная половина - это железо, и еще половина - приложения. Поэтому, учить людей настраивать или мониторить Windows и Linux - нет ни малейшего желания.

Впрочем, почти два года назад я написал вот это
http://www.ibase.ru/devinfo/optimize.htm
но так и не опубликовал. Кажись сюда выкладывал для обсуждения, но не нашел такого топика, может склероз.

Симонов ДенисА что в тройке у классика разве уже может быть общий кэш? Я думал это только у супера сделано и он стал многопоточным.
статья писалась, пока и альфы не было. Потому такое упоминание. По идее, надо будет подрихтовать по текущему состоянию, но я не очень люблю писать, о том "что будет, и чем сердце успокоится". До перехода FB 3.0 в состояние хотя бы beta это будет только засорять статью (как мне кажется).