Как контролировать рост временных файлов в SQL Anywhere?
В настоящее время мы сталкиваемся с растущей проблемой временных файлов. Просматривая один из наших сайтов, мы видим рост на 100 - 200 МБ в день на одном сайте, который мы наблюдаем. На этом сайте произошел сбой, когда временный файл достиг 20 ГБ и возникла проблема свободного места.
В настоящее время мы подавляем таймауты. -ti и -tl установлены в ноль. Какова вероятность того, что временные таблицы создаются из-за этой конфигурации?
Дополнительно. Для более глубокого понимания флага -tl приведем следующее верное утверждение: Соединение не будет сброшено, если клиент не может быть доступен через tcpip.
2 ответа
Маловероятно, что -ti 0 или -tl 0 имеют какое-либо отношение к проблеме временного пространства в SQL Anywhere. Скорее всего, это результат неудержимого запроса. Если вы используете версию 9, вы можете включить проверку лимита следующим образом:
SET OPTION PUBLIC.temp_space_limit_check = 'ON';
В версиях 10 и 11 эта опция уже должна быть включена, но, возможно, она отключена. Новая опция max_temp_space также полезна.
В более ранних версиях вам просто нужно было найти убегающие запросы; Foxhound может помочь: http://www.risingroad.com/foxhound/index.html
Смотрите также "Опасно! Запросы на печать!" по адресу http://sqlanywhere.blogspot.com/2009/03/danger-queries-are-stampeding.html
К вашему сведению, параметр -ti 0 неограниченное время бездействия очень часто встречается, когда вы ожидаете длительные периоды бездействия; например, на ночь в большом сетевом пуле соединений.
Однако параметр -tl 0 неограниченное время жизни фактически опасен, если он приводит к скоплению большого количества зомби-соединений (клиенты давно мертвы, но сервер держит соединения открытыми). Как говорится в справке, обычно лучше увеличить период ожидания, если у вас возникли проблемы с преждевременным выходом из жизни; например, -tl 3600 за один час.
AFAIK утверждение "Соединение не будет сброшено, если клиент не может быть доступен через tcpip", кажется слишком упрощенным: проверка пакетов живучести кажется более сложной, чем простой тест "не может быть достигнут".
Брек
Вы правы, что ключи -ti и -tl не связаны с временным пространством.
Что касается вопроса живучести, то и клиент, и сервер отправляют пакеты живучести каждый раз. n/3 секунд, где n это значение времени жизни. Это происходит только в том случае, если за это время не было отправлено никаких других пакетов. Если одна из сторон не получила никаких пакетов от другой стороны после n секунд соединение обрывается.
Жизнеспособность не требуется в случае, когда соединение фактически сбрасывается другой стороной (например, происходит сбой приложения / сервера или перезагрузка машины), поскольку соединение TCP будет немедленно закрыто. Однако жизнеспособность полезна для обнаружения зависших приложений и сетевых проблем, которые мешают прохождению пакетов, но не приводят к обрыву TCP-соединения.