PgConf.Russia 2019

Несколько реальных кейсов от тех кто остановил переход на PostgreSQL.

Хорошо, когда база работает предсказуемо. Если сервер не справляется с нагрузкой, то только знай добавляй процессорные ядра, терабайты оперативной памяти и миллионы IOPS'ов – всё станет хорошо. Гораздо неприятнее, когда у сервера куча свободных ресурсов, но база данных всё равно тормозит. И особенно обидно, когда при нагрузочном тестировании всё работало как часы, а при реальной нагрузке такого же объёма – встаёт колом.

В данном докладе я разберу "узкие места" постгреса, которые нам приходилось встречать в реальной жизни, и которые приводили к печальному поведению, как описано выше. Расскажу о том, что можно сделать на пользовательском уровне, что эти "узкие места" обойти, и о том, что планируют сделать разработчики, чтобы их вообще убрать. А также поделюсь некоторыми рецептами нагрузочного тестирования, которые помогут избежать неожиданностей в продакшене.

Виртуализация в компаниях стала альтернативой консервативного подхода "одна задача - один сервер", позволяющая эффективно использовать аппаратные ресурсы, централизованно управлять серверной инфраструктурой, экономить электроэнергию и ресурсы на охлаждение. В докладе рассказывается о настройке среды VMware для интенсивного ввода-вывода PostgreSQL и инструментах профилирования виртуальной инфраструктуры для контроля производительности и устранения выявленных проблем.

Мы - обычные разработчики, которые думали о том, как разработать систему, способную выдерживать неплохие нагрузки, и это даже получилось.

На уровне архитектуры всё было OK, но объём данных возрастал, и начали вылезать не самые приятные моменты, о которых ранее никто не думал и не понимал. Иногда это приводило нас к самым потрясающим запросам, которые мы не понимали, как можно было написать. Мой небольшой рассказ будет о том, как получить нагрузку в БД на пустом месте и как потом от неё избавиться.