TransCom,

значит, памяти мало.

TransComвариант нарастить ОЗУ - это значит увеличить кэш для процессов fb(стоит classic) или просто в сервере(елси да - то насколько много надо??? сейчас стоит 80Гб)?
на классике оптимальный кэш - от 512 до 2048 страниц, максимум.
У меня вопрос - а разве нельзя посмотреть, сколько памяти сейчас куда используется на сервере? Если винда, то это rammap, если линукс, то ... чем-то другим.
Если 80 гиг памяти поделить примерно на 250 мб каждого процесса, то выходит 350 процессов классика, и если предположить меньше, по 150мб на процесс, то этого явно недостаточно.

TransCom а вдруг создастся lock файл не 83Мб, как сейчас, а 200Мб, тогда видимо проблем не избежать.
ну-ну
LockMemSize >= Cache_pages * max_connections_count * 100

Текущий размер lockmemsize смотрится в fb_lock_print. Если до 500 коннектов, и кэш БД стоит 1024 страниц, то минимум - это 50 мегабайт.
Если памяти под блокировки не хватает, то выделяется новый кусок, старое копируется туда.
Скорее всего вы напоролись на просмотр "скорости записи" в этот файл в какой-то такой момент. Или когда действительно стало не хватать памяти.
Собственно, сильно подозрительно, что в лок-файл "постоянно идет запись", при этом процессы занимают 20 гиг памяти, а 60 операционка отдала под файловый кэш.
Размер базы-то какой?

TransCom3 месяца назад работал тот же сервис на 64Гб памяти и было все отлично
допустим, кэш БД был 512 страниц. А потом, когда стало 80 гиг памяти - кто-нибудь ляпнул: "а давайте кэш увеличим". И поставили 1024 страницы. И потребляемая память существенно увеличилась.
Или, как обычно - поменяют сразу несколько параметров - конфиг оси подкрутят, памяти добавят, и еще чего-нибудь.
А потом гадают - что-же такого произошло, что стало только хуже?

TransComVersion: 145, Active owner: 0, Length: 83886080, Used: 83568664
это для 350 коннектов. Так что чуть больше будет, и опять память лок-менеджер будет увеличивать.
Так что, 83мб мало. Надо ставить 100мб, не меньше.
Еще, на мой дилетантский по линуксу взгляд, Дебиан тут не в кассу. Центос - да, пожалуйста.
И еще, мы не услышали про размер базы и размер страницы кэша БД, в конфиге и в заголовке БД (gstat -h).

Собственно, 300 юзеров - это уже надо хорошо разбираться и в настройке линукса, и в конфиге ФБ, и в собственном железе.

hvlad,

да там непонятно, это в конфиге 83мб, или доехало само. Не исключаю первое, конечно.

TransComесли он итак для классика сам вырастет до нужного размера?
я уже писал, что при росте этот кусок памяти целиком перераспределяется. Чтобы этого избежать, надо задать необходимый максимальный размер сразу. Он определяется по лок-принту, в момент максимального кол-ва коннектов.
TransComPage buffers 3000
это в заголовке БД прописано? Ваша лаконичность совершенно не к месту.
Для классика 3000 страниц кэша - это много. Надо 1024, это самый оптимум. Можно экспериментировать до 2048, но вряд-ли больше.
Одновременно надо смотреть, что указано в конфиге, DefaultDbCachePages, и закомментировано или нет.
TransComРазмер БД 3.8Гб
это весьма небольшая БД. А значит она целиком в кэше. А значит, что с ваших слов 60 гиг кэша сейчас - это слишком дофига, и у вас на этом сервере, вероятно, крутится что-то еще, что вытесняет ФБ из памяти.

Почитайте хотя бы вот это
http://www.ibase.ru/files/firebird/Firebird_Hardware_Guide_2015_rus.pdf

TransComБарьер включен
http://www.sql.ru/forum/895986/ext4-barrier-0-ili-1
TransCom процессы fb съедают диск, на котором нет базы, а только темп директория, откуда я знаю, что это именно этот лок-файл?
а может это временные файлы fb_... ? Если запросы с plan sort, то вполне возможно.

TransCom Лок файла, конечно не уверен, но думаю что это именно он! Во-первых тяжёлых запросов у меня нет, это принципиальная вещь
я нифига не понимаю, но если попробую потыкать вот там и здесь, то может быть, и т.д.
Приеципиально тяжелые запросы ты можешь отловить только трейсом. Про который ты понятия не имеешь.