Dmitrii, может быть. Вот у них такой консервативный путь развития. Наверное в вопросах где цена ошибки - человеческая жизнь - не может быть компромиссов.
BaJIepaMoTo6JIok, да. Но slow log тебе не покажет свободное место на pg_stat.
Поэтому параллельно запускай cron который будет делать df -h или du или что-то в этом
роде для более точного поиска времени сбоя.
BaJIepaMoTo6JIok, ну то что ты придумал ребутать - это ты конечно молодец. Но это решение временное
и надо фиксить. Попробуй джобом через каждые 5 минут делать снимок таблицы с тяжелыми запросами
которые работали долго. И сохраняй в текстовые файлы. Утром - почитаешь.
Я такое делал в Oracle, но в PG я к сожалению не помню как эта VIEW называется. Но она точно есть в PG.
После того как ты будешь знать в лицо этот SQL запрос - будет понятна стратегия как с ним воевать.
Может просто там индекса не хватает. Или таблицу пора почистить.
На момент возиникновения ситуации посмотри какой размер у файла pg_stat/db_14658792.tmp
Если взять толстую таблицу и сортировать ее сразу по всем колонкам то SQL машина может
затребовать много памяти. Может проблема комплексная и тут просто растягиваением диска или
ребутами ты ее не решишь.
И ребут базы это вообще не решение проблемы. Ведь это отказ в обслуживании по сути.
Какой-то SQL запрос был сбит на взлете.
Мне кажется это так не решается. В течение дня обстановка на дорогах может менятся. Тоесть маршрут,
построенный утром к обеду может быть не актуален и надо будет все заново перерасчитывать.
Ну к задача коммивояжера - это вроде уже решенная задача в гео-системах.
My1Name, вы конечно очень мотивируете вам помогать :)
Какой у вас вообще предполагался сценарий? Потому что в коде который приведет тоже нет
понимания времени исполнения. При каждом старте приложения? При каждом старте бизнес-процесса?
В крупных корпорациях всегда есть отдел безопасности. ОИБ. И там обычно сидят бывшие менты и
особисты. А у них - очень много каналов проверки физ-лиц. И вообще неудивительно что корпорации
собирают сведенья о людях. Это часть политики HR отдела. Они должны знать с кем работают.
Пробив или не пробив - это не имеет значения. Я-бы назвал это сбором бигдаты для принятия решений.
И иногда эта бигдата может быть просто куплена.