Про рекомендацию техподдержки это понятно. Как раз идет тестирование на нагрузочном стенде . Задача посмотреть какая будет разница между 0/8/16/32.
Пока, проблема следующая. Посмотреть ожидания LWLock можно , но пока не очень понятно как определить какую блокировку ждет процесс - разделяемую или эксклюзивную.
Разве, что догадаться по столбцу wait , представления pg_stat_activity или pg_wait_sampling. Но и тут есть неоднозначности , например : "Ожидание при чтении или изменении текущего состояния рабочих процессов автоочистки." И вот как догадаться это ожидание при чтении или изменении ?
Я лично знаю не одну информационную систему которые регулярно падают, и в промышленной эксплуатацию без нагрузочного тестирования. Так, что насчет подгорания это страшилки для джунов. В реальном мире все несколько иначе.
По житейскому опыту - когда день кончился и все упало - легче и проще.
Клиентов почти нет , нагрузки нет , топов нет , манагеров почти нет . Проблема как правило в железе или виртуализации.
А вот когда днём - совсем другие шаманские танцы начинаются . Основной мотив - мы упёрлись в СУБД, дайте нам серебряные пули и волшебный эликсир . И конечно стандартная игра в футбол , переходящая в волейбол - "у нас всё хорошо , проблема не в приложении".
Увы, это реальность IT, сейчас большая часть сегмента разработчиков это чайки-попрыгунчики, которые научились правильно проходить собеседование и на этом все. В 80% случаев таким чайкам вообще похер чем и как они занимаются - они пришли стучать по клавиатуре получать за это много денег.
Да. Поэтому , данный пост просто озвучивание мыслей вслух. Проблема с разрабами не решаемая. А с удешевлением ресурсов и нет особого смысла в оптимизации и тонкой настройке. Добавили терабайт RAM и вперед. До следующего завала.
Strategy to be used in creating the new database. If the WAL_LOG strategy is used, the database will be copied block by block and each block will be separately written to the write-ahead log. This is the most efficient strategy in cases where the template database is small, and therefore it is the default. The older FILE_COPY strategy is also available. This strategy writes a small record to the write-ahead log for each tablespace used by the target database. Each such record represents copying an entire directory to a new location at the filesystem level. While this does reduce the write-ahead log volume substantially, especially if the template database is large, it also forces the system to perform a checkpoint both before and after the creation of the new database. In some situations, this may have a noticeable negative impact on overall system performance.
Про рекомендацию техподдержки это понятно. Как раз идет тестирование на нагрузочном стенде . Задача посмотреть какая будет разница между 0/8/16/32.
Пока, проблема следующая. Посмотреть ожидания LWLock можно , но пока не очень понятно как определить какую блокировку ждет процесс - разделяемую или эксклюзивную.
Разве, что догадаться по столбцу wait , представления pg_stat_activity или pg_wait_sampling. Но и тут есть неоднозначности , например : "Ожидание при чтении или изменении текущего состояния рабочих процессов автоочистки." И вот как догадаться это ожидание при чтении или изменении ?
в этом то и основной вопрос - "Что значить хуже?" Тут без нагрузочного тестирования никак конечно.
Я лично знаю не одну информационную систему которые регулярно падают, и в промышленной эксплуатацию без нагрузочного тестирования. Так, что насчет подгорания это страшилки для джунов. В реальном мире все несколько иначе.
Добавлю свои 5 копеек:
1) Уронил прод на Оракле запросом к недокументированному представлению
2) ошибся с pid для kill -9 и прибил системный процесс PostgreSQL
Сорри, но это всё.
По житейскому опыту - когда день кончился и все упало - легче и проще.
Клиентов почти нет , нагрузки нет , топов нет , манагеров почти нет . Проблема как правило в железе или виртуализации.
А вот когда днём - совсем другие шаманские танцы начинаются . Основной мотив - мы упёрлись в СУБД, дайте нам серебряные пули и волшебный эликсир . И конечно стандартная игра в футбол , переходящая в волейбол - "у нас всё хорошо , проблема не в приложении".
Местами даже весело ...
Мы не можем проводить нагрузочное тестирование , у нас сроки горят .
Хорошо, когда точно известна причина падения .
В жизни как правило, чуть другой сценарий - рабочий день начался , пришли пользователи - прод упал.
И начинается самое интересное - "Кто виноват? Что делать?"
Вопрос не - кто виноват?
Вопрос - что делать ?
Да. Согласен - именно так. Исправлено
И какие же результаты кроме поста в Хабр ?
Да. Поэтому , данный пост просто озвучивание мыслей вслух. Проблема с разрабами не решаемая. А с удешевлением ресурсов и нет особого смысла в оптимизации и тонкой настройке. Добавили терабайт RAM и вперед. До следующего завала.
Про ошибки sql
Анализировать код возврата это раньше была классика.
А так получается backend вызывает запрос к СУБД, запрос возвращает ошибку . И backend идет дальше - ой, а умна почему, то не работает форма .
кол-во активных / кол-во подключение - это не производительность, это нагрузка на СУБД
Это вам так кажется, скорее всего.
Просто разработчики вежливы и не говорят, как со стороны выглядит когда менеджер начинает вести беседу на технические темы.
А какие метрики , лично вы используете для мониторинга производительность СУБД?
А когда вся ИС не работает при использовании эксклюзивных блокировок это нормальные накладные расходы?
ISOLATION LEVEL SERIALIZABLE чем не устраивает ?
Это все конечно прекрасно, по каждому пункту. Дело за малым - объяснить всё это новому поколению разработчиков и менеджеров.
strategy
Strategy to be used in creating the new database. If the
WAL_LOG
strategy is used, the database will be copied block by block and each block will be separately written to the write-ahead log. This is the most efficient strategy in cases where the template database is small, and therefore it is the default. The olderFILE_COPY
strategy is also available. This strategy writes a small record to the write-ahead log for each tablespace used by the target database. Each such record represents copying an entire directory to a new location at the filesystem level. While this does reduce the write-ahead log volume substantially, especially if the template database is large, it also forces the system to perform a checkpoint both before and after the creation of the new database. In some situations, this may have a noticeable negative impact on overall system performance.create database - параметр стратегия.
Возможно , чуть позже будет статья о последствиях.
Итог - крах СУБД.
Пришлось вносить изменение в сервисный скрипт.