Pull to refresh
11
0.2
Ринат Сунгатуллин @rinace

Администратор баз данных PostgreSQL

Send message

Про рекомендацию техподдержки это понятно. Как раз идет тестирование на нагрузочном стенде . Задача посмотреть какая будет разница между 0/8/16/32.

Пока, проблема следующая. Посмотреть ожидания LWLock можно , но пока не очень понятно как определить какую блокировку ждет процесс - разделяемую или эксклюзивную.

Разве, что догадаться по столбцу wait , представления pg_stat_activity или pg_wait_sampling. Но и тут есть неоднозначности , например : "Ожидание при чтении или изменении текущего состояния рабочих процессов автоочистки." И вот как догадаться это ожидание при чтении или изменении ?

в этом то и основной вопрос - "Что значить хуже?" Тут без нагрузочного тестирования никак конечно.

Я лично знаю не одну информационную систему которые регулярно падают, и в промышленной эксплуатацию без нагрузочного тестирования. Так, что насчет подгорания это страшилки для джунов. В реальном мире все несколько иначе.

Добавлю свои 5 копеек:

1) Уронил прод на Оракле запросом к недокументированному представлению

2) ошибся с pid для kill -9 и прибил системный процесс PostgreSQL

Сорри, но это всё.

По житейскому опыту - когда день кончился и все упало - легче и проще.

Клиентов почти нет , нагрузки нет , топов нет , манагеров почти нет . Проблема как правило в железе или виртуализации.

А вот когда днём - совсем другие шаманские танцы начинаются . Основной мотив - мы упёрлись в СУБД, дайте нам серебряные пули и волшебный эликсир . И конечно стандартная игра в футбол , переходящая в волейбол - "у нас всё хорошо , проблема не в приложении".

Местами даже весело ...

Мы не можем проводить нагрузочное тестирование , у нас сроки горят .

Хорошо, когда точно известна причина падения .

В жизни как правило, чуть другой сценарий - рабочий день начался , пришли пользователи - прод упал.

И начинается самое интересное - "Кто виноват? Что делать?"

Вопрос не - кто виноват?

Вопрос - что делать ?

Да. Согласен - именно так. Исправлено

Мы уже начали работать в этом направлении.

И какие же результаты кроме поста в Хабр ?

Увы, это реальность IT, сейчас большая часть сегмента разработчиков это чайки-попрыгунчики, которые научились правильно проходить собеседование и на этом все. В 80% случаев таким чайкам вообще похер чем и как они занимаются - они пришли стучать по клавиатуре получать за это много денег.

Да. Поэтому , данный пост просто озвучивание мыслей вслух. Проблема с разрабами не решаемая. А с удешевлением ресурсов и нет особого смысла в оптимизации и тонкой настройке. Добавили терабайт 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 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.

create database - параметр стратегия.

Возможно , чуть позже будет статья о последствиях.

Итог - крах СУБД.

Пришлось вносить изменение в сервисный скрипт.

Information

Rating
2,049-th
Location
Россия
Date of birth
Registered
Activity