В настоящее время мы сталкиваемся с растущей проблемой временных файлов. Наблюдая за одним из наших сайтов, мы можем увидеть рост на 100-200 МБ в день на одном сайте, который мы наблюдаем. На этом сайте произошел сбой, когда размер временного файла достиг 20 ГБ, и возникла проблема со свободным пространством.
В настоящее время мы подавляем тайм-ауты. -ti и -tl установлены в ноль. Какова вероятность того, что временные таблицы накапливаются из-за этой конфигурации?
Дополнительно. Чтобы лучше понять флаг -tl, следующее истинное утверждение: соединение не будет сброшено, если клиент не может быть достигнут через tcpip.
Маловероятно, что -ti 0 или -tl 0 имеют какое-либо отношение к проблеме временного пространства в SQL Anywhere. Скорее всего, это результат неконтролируемого запроса. Если вы используете версию 9, вы можете включить проверку лимита следующим образом:
УСТАНОВИТЬ ОПЦИЮ PUBLIC.temp_space_limit_check = 'ON';
В версиях 10 и 11 эта опция уже должна быть включена, но, возможно, она отключена. Также полезна новая опция max_temp_space.
В более ранних версиях вам просто нужно было найти неконтролируемые запросы; Фоксхаунд может помочь: 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», кажется чрезмерным упрощением: проверка пакетов жизнеспособности кажется более сложной, чем простой тест «не может быть достигнут».
Breck
Вы правы в том, что переключатели -ti и -tl не связаны с временным пространством.
Что касается проблемы живучести, то и клиент, и сервер отправляют пакеты работоспособности каждые n/3 секунды, где n - значение тайм-аута живучести. Это происходит только в том случае, если за это время не было отправлено никаких других пакетов. Если одна из сторон не получила пакетов от другой стороны после n секунд, соединение разрывается.
Живучесть не требуется в случае, когда соединение фактически разорвано другой стороной (например, происходит сбой приложения / сервера или перезагрузка машины), поскольку TCP-соединение будет немедленно закрыто. Однако живучесть полезна для обнаружения зависших приложений и сетевых проблем, которые препятствуют прохождению пакетов, но не вызывают разрыва TCP-соединения.