Мимопроходящий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
Я так понимаю, надо непосредственно перед свипом смотреть: