всем доброго дня вот top

а вот iotop

База как правило растет до 3ГБ и потом ее режут и чистят после этого она за месяц с 2.5 гигов за месяц опять дорастает до 3ГБ

по поводу дисков 2 ssd первый рейд, hdd под бэкап

kdvpastorесли он в пределах 1 Гб, то конфигом это не лечится. и тп. и пр.
из разряда телепатии - "тяжелый отчет" представляет собой запрос с plan sort, в результате чего io в temp пожирает ресурсы, или шедулер io блокирует альтернативные операции, в результате чего все приходит в ступор.

Собственно, имеем следующую ситуацию
- пользователь стороннего ПО
- от стороннего ПО нет нигде рекомендаций ни по оборудованию, ни по настройке ФБ (на сайте не нашел)
- рекомендация ubuntu в качестве сервера БД не объяснена. "рекомендует производитель ПО" - это на грани бреда.
- кто ставил и настраивал убунту - неизвестно
- почему старый сервер поменяли на новый - неизвестно.
- как и где что лежит на этих 128/128/500 - тоже неизвестно
- что в firebird.conf - неизвестно
- что происходит в системе (операционке) при выполнении "тяжелого отчета" и без него - неизвестно

Единственное, что известно:
- с транзакциями вроде все ок, более того, 72301 транзакций с марта - это 12 транзакций в день. Как бы, не очень верится, если работают 35 человек.
- база в no reserve, по неизвестной причине. Я знаю только один случай, когда разработчик явно объяснил причину выставления этого флага в базе. В остальных случаях "никто ничего не знает".

вроде все. Опять подчеркну, что при этих условиях крутить firebird.conf нужно в последнюю очередь (если он случайно кем-то уже не редактировался).
На транзакции не смотрите, в этой базе ни кто не работает с марта, просто именно вней все настройки профильных систем правильные, поэтому пока ее для теста прикрутили

kdvmiwaonlineЕсли серьезно - может куда-то в прилепленную тему воткнуть мысли о расчете этого параметра
т.е. тупо людей учить умножению? page_size * cache_size * process_count = ?
http://www.ibase.ru/devinfo/optimize.htm

voron543сейчас при 8 гигах тормозит даже при одном пользователе т.е дело не в оперативке
значит или диска все же не хватает, или запрос такой, что жрет проц, и долго.
Вы хоть куда-нибудь в операционку можете посмотреть, что в ней происходит? Администратор приходящий есть?
Хорошая ссылка, респект! очень интересно!

еще в догонку пробовал менять DefaultDbCachePages на 512 и на 2048, и вообще не запустилось приложение , как то странно. Хотя на старом сервере с виндой и SS вообще стоит 8196

Симонов Денис,

ага, гоню, после ребута подключился

o_v_avoron543пропущено...

Да
"Да" на хлеб не намажешь!
Я просто так что ли спрашивал? Я для того спрашивал, чтоб ты показал вывод СЮДА, чтоб все видели, какой процесс слушает порт 3050
у нас не по 3050 а по 3070 рабоатет, если вам даст что то статистика с боевого сервера на винде И SS
Database header page information:
Flags 0
Checksum 12345
Generation 836904
Page size 4096
ODS version 11.0
Oldest transaction 712507
Oldest active 712508
Oldest snapshot 712508
Next transaction 836895
Bumped transaction 1
Sequence number 0
Next attachment ID 449
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Oct 27, 2013 21:47:21
Attributes force write, no reserve

Variable header data:
Sweep interval: 20000
*END*

Симонов Денис,

да, после попробовал подгрузить расчет в базу вес 1,5 мб ,клиент повис

[quot kdv]voron543База как правило растет до 3ГБ и потом ее режут и чистят после этого она за месяц
мне интересно, а зачем в самом начале было приводить статистику от другой БД?

Затем что это статистика новго сервера , который нужно настройить, а вторая статистика тот который мы хотим убирать

kdv
если статистика снята вчера, т.е. база существует всего 3 дня, то это получается 279 тысяч транзакций в сутки, что для 35 человек означает 7970 транзакций на одного, и 996 транзакций в час, или 16 транзакций в минуту. Непрерывно. Что опять похоже на какое-то вранье (если не считать каких-нибудь массовых пакетов транзакций по импорту/обновлению данных.

Ну и, самое главное - транзакция у вас активная висит, примерно 4 часа, от того момента как снята статистика. При такой интенсивности транзакций это вполне может накопить дохренища версий, что и даст тормоза.
А я Альтвин же учил, что надо избавляться от этого дела.

voron543Sweep interval: 20000
это еще что за хрень при таких показателях?
Работа идет 24 в сутки, постоянный обмен данными с 1с и другими дилерскими версиями прорамы