Всем привет.

На днях на сервере случился "бадабум": база внезапно (в течение часа-двух примерно) выросла с ~230 Гб до >400 Гб.
Наверное, выросла бы и больше, если бы не закончилось место на диске.

Спасло наличие второго сервака на репликации и вчерашней копии nbackup.

Разбираться в причинах времени не было, девать эти 400 Гб тоже было некуда (сервер у провайдера на коллокейшене, по инету качать долго, согласовывать физический доступ тоже долго), пришлось их удалить.

Вероятнее всего, запустили отчет с неверными датами на входе и получили чудовищную кучу временных блобов.
Приложение мы поправим, чтобы такого не повторялось, но вопрос не в этом.

Вопрос в том, как защититься от такого катастрофического роста объема базы ?

На сервере win 2003 (на другом 2008), FB 2.5.4, CS, 32bit (есть удф-ки).

Пока только вижу вариант с дисковыми квотами. Но это защитит не от роста базы, а от пожирания всего диска, т.е. полумера. Да и по мере естественного роста базы придется эти квоты периодически увеличивать.

Можно ли, например, как-то ограничить аппетиты FB по части временных блобов ?

МимопроходящийHello, Сисдба Мастеркеевич!
You wrote on 7 мая 2015 г. 17:06:56:

Сисдба Мастеркеевич> Можно ли, например, как-то ограничить аппетиты FB
> по части временных блобов ?не пихать их куда ни попадя

Они имеют привычку возникать "сами"

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

а чего там кидать. Либо мусор не собирается, либо плодятся временные блобы ( хотя при сборке мусора и они не проблема )Таки проблема. Ибо простым запросом, который ты же и привел, даже не имея прав ни на какие таблицы, можно распушить базу до пределов всего свободного места.

Интересно, есть ли в планах разработки FB не хранить временные блобы в базе ? Можно ведь, наверное, их хранить во временных файлах ? Или сервер не знает, останется ли блоб временным ?

Dimitry SibiryakovСисдба МастеркеевичМожно ведь, наверное, их хранить во временных файлах ?

Тебе с одним диском это не поможет.
Диск, конечно, не один.
Если база распухла, то что с ней делать ? Backup/restore ? сотни гиг ? А если еще облом во время рестора ?
А временные файлы, во-первых, можно на другой диск определить; во-вторых, они самоликвидируются, когда коннект, вызвавший проблему, отвалится. Остальные коннекты, если и пострадают, то весьма временно.

hvladСисдба МастеркеевичНа днях на сервере случился "бадабум": база внезапно (в течение часа-двух примерно) выросла с ~230 Гб до >400 Гб.
Наверное, выросла бы и больше, если бы не закончилось место на диске.

Спасло наличие второго сервака на репликации и вчерашней копии nbackup.От чего спасло ? Что заставило поднимать БД из бекапа\копии ?Спасло от отсутствия свободного места на диске с базой.
Пришлось файл базы удалить и восстановить вчерашний из копии.
Файл базы ведь не подрежешь, и к диску место не пришьешь.

Симонов ДенисСисдба Мастеркеевич,




оставь как есть. Как только транзакция создавшая временный блоб будет завершена это пространство можно будет использовать повторноМесто в базе - да, будет использовано повторно, а свободное место на диске с базой не появится, а оно нужно ... внезапно так.

Dimitry SibiryakovСисдба Мастеркеевичсвободное место на диске с базой не появится, а оно нужно ...
внезапно так.

Действительно внезапно. Для чего нужно это место?
Дак FB ругается в лог:
А работать то надо, начальники тоже ругаются.

МимопроходящийHello, Сисдба Мастеркеевич!
You wrote on 8 мая 2015 г. 14:36:26:

Сисдба Мастеркеевич> I/O error during "WriteFile" operation for file "D:\TEMP\FB_TABLE_3YWUTM"
> Error while trying to write to file
> Недостаточно места на диске.
TEMP на том же диске что и база?
Физических дисков на сервере 8 штук. Из 6 сделан RAID-10, 2 - не в райде, для системы, резервных копий и прочего. База и темпы на райде, ибо он типа быстрый и умный.

Dimitry SibiryakovСисдба МастеркеевичI/O error during "WriteFile" operation for file
"D:\TEMP\FB_TABLE_3YWUTM"
Error while trying to write to file
Недостаточно места на диске.
А кто-то тут утверждал, что диск не один и временные файлы лежат совсем отдельно...
Я говорил о том, что это можно сделать.

МимопроходящийHello, Сисдба Мастеркеевич!
You wrote on 8 мая 2015 г. 14:47:04:

Сисдба Мастеркеевич> Файл базы ведь не подрежешь, и к диску место не пришьешь.
касаемо "пришивания места к диску" ты глубоко заблуждаешься.
даже на win, не говоря уж про linux.
В теории возможно многое.
На практике, в нашем случае, чтобы прирастить место, надо было:
1. Договориться с провайдером о физическом доступе к серверу (несколько часов)
2. Быстро найти дополнительные диски (хорошо, пусть они есть заранее запасенные)
3. Найти, куда засунуть эти диски на сервере. Хорошо, меняем полностью набор дисков в массиве.
4. Построить новый массив, скопировать туда (откуда-то) проблемную базу и еще 2 базы, которые там же были, тоже >100 Гб каждая. Базы эти мало используются, туда только заливаются данные, но они тоже нужны в работе.
5. Запустить всё в работу.

В итоге это всё выльется в целый рабочий день и не гарантирует неповторения ситуации.

К тому же, 170 Гб мусора в базе - не айс, он ведь и в копии попадает, их тоже где-то надо хранить.

Dimitry SibiryakovСисдба МастеркеевичЯ говорил о том, что это можно сделать.
Это нужно сделать. Вне зависимости от. А в твоём случае остаётся только повторить,
что временные блобы во временных файлах на том же диске - не помогут.
Смотри.
Есть дисковое пространство ~800 Гб.
1 вариант: создаем один раздел на всё пространство, в нем живут и темпы, и база. Темпы - меняются, они могут как прирастать в объеме, так и уменьшаться. База - может только прирастать. Таким образом, мы имеем потенциальную возможность роста базы до ~800 Гб, с уменьшением места для темпов, что не сильно критично для работы (у нас нет больших сортировок и не пишем много во временные таблицы).
2 вариант: создаем 2 раздела, один для темпов, скажем, 100 Гб, второй - для базы, 700 Гб. Теперь мы имеем потенциальную возможность роста базы до ~700 Гб, с постоянным объемом места для темпов.

Во втором варианте мы искусственно уменьшаем предел роста базы за счет увеличения свободы для относительно малозначимых темп-файлов.

Теперь посмотрим, что было бы в моем случае, если бы временные блобы жили в темп-файлах: база бы не увеличилась до предела, а всё место заняли бы темпы. В таком случае кривой запрос просто обломится, коннект отвалится, темпы убьются, место освободится - вуаля, можно продолжать работать дальше.

Тот пользователь, у кого обломился запрос, прибежит к программисту жаловаться, что у него что-то там не открывается. Программист попробует воспроизвести и сразу увидит причину.
А сейчас пришлось за неимением времени и места на дисках убить распухшую базу, потратить немало времени на восстановление работоспособности сервера и проводить следствие по логам, чтобы понять, что же произошло.

ИМХО, хранение временных блобов в базе - это уязвимость сервера, существенная, хоть и редко встречающаяся на практике. Да и хранить в базе мусор, который нужен только на время запроса и более не потребуется никому и никогда - это расточительно.

Я понимаю, что сейчас в сервере с временными блобами ничего не изменить, можно не обвинять меня в том, что я чего-то требую :) Я хочу понять, как не допустить в будущем подобной ситуации, т.е. неконтролируемого и быстрого роста базы.

Dimitry SibiryakovСисдба МастеркеевичТеперь посмотрим, что было бы в моем случае, если бы временные
блобы жили в темп-файлах: база бы не увеличилась до предела, а всё место заняли бы темпы.
В таком случае кривой запрос просто обломится, коннект отвалится, темпы убьются, место
освободится - вуаля, можно продолжать работать дальше.
В твоём случае проблема возникла не из-за нехватки места под базу, а как раз из-за
нехватки места под временные файлы. Когда база упирается в свободное место, всё именно так
и происходит: кривой запрос обламывается, транзакция откатывается, место освобождается -
вуаля, можно ещё некоторое время поработать (по крайней мере на чтение). Временные файлы
используются в гораздо большем количестве случаев, поэтому из-за нехватки места в TEMP и
упало сразу всё.
Судя по логам, ошибки нехватки места начали появляться около 12.30. Окончательно всё упало около 15.30. Кривой запрос был запущен около 11.00.
Скорее всего, первый раз нехватка места произошла из-за частичного подрастания базы и существенного объема, занятого темпами. в 12.30 кривой запрос отвалился, темпы убились, но база не уменьшилась. Скорее всего, кривой запрос пытались запустить еще не раз (правда, я в логах нашел только один повторный запуск). В результате таких итераций база распухла до пределов всего раздела, места не осталось и работать стало невозможно.

Да, коннекты у нас осуществляются с отключенной сборкой мусора, ибо со сборкой работает медленнее.
Мусор убирается ночами во время свипа.

Вопрос: если бы коннект был со сборкой мусора, то при повторных запусках кривого запроса было бы использование того места в базе, которое было выделено под временные блобы в предыдущих попытках ?


авторКогда база упирается в свободное место, всё именно так
и происходит: кривой запрос обламывается, транзакция откатывается, место освобождается -
вуаля, можно ещё некоторое время поработать (по крайней мере на чтение)Каким образом место освобождается, если темпы на другом диске (ты ведь про этот вариант пишешь) ? Или ты имеешь в виду место под темпы ? В любом случае, работа только на чтение - не вариант.

МимопроходящийHello, Сисдба Мастеркеевич!
You wrote on 8 мая 2015 г. 17:22:37:

Сисдба Мастеркеевич> Да, коннекты у нас осуществляются с отключенной сборкой мусора,
> ибо со сборкой работает медленнее.
клиентские приложения спроектированы очень плохо.
или даже совсем никак.
какой разрыв в транзакциях набегает за день?

gstat -h
Я так понимаю, надо непосредственно перед свипом смотреть: