БД — большой кэш

В прошлый раз я обещал написать о том, что в проектах с более менее серьезной нагрузкой БД либо помещается в память, либо не работает. Ситуация в современном мире меняется в связи с появлением SSD дисков, но пока что они стоят достаточно дорого, по сравнению со старыми добрыми вращающимися дисками. Чтобы «потрогать» это руками, проделаем несложный тест.

Я завел новую машину с Ubuntu 12.04, на облачном хостинге Amazon размера t1.micro. После этого необходимо поставить 2 пакета: postgresql-contrib-9.1 и ruby.

PostgreSQL contrib содержит, помимо всего прочего, программу pgbench, специально предназначенную для нагрузочного тестирования PostgreSQL.

В postgresql.conf параметр shared_buffers был выставлен в 64MB.

Далее был написан скрипт на ruby, который проводил тестирование:

File.open('res.txt', 'w') do |f|
	(1..50).each do |s|
		# -i означает, что мы создаем чистую БД
		# -s - это scale factor, определяет размер БД
		`/usr/lib/postgresql/9.1/bin/pgbench -i -s #{s}`

		# -S - тесты для запросов только на чтение
		# -T 20 - тест длится 20 секунд
		# -c 40 - 40 клиентов
		# -j 4 - 4 потока
		res = `/usr/lib/postgresql/9.1/bin/pgbench -c 40 -j 4 -S -T 20`
		puts res
		f.write res
	end
end

Более подробно про pgbench можно почитать в официальной документации.

На машинках t1.micro free -m выдает следующее:

             total       used       free     shared    buffers     cached
Mem:           590        583          6          0          1        428

Именно этим обусловлен такой выбор границ scale factor. Про scale factor = 50 размер БД приблизительно 750Мб, то есть больше количества доступной памяти, а граница shared_buffers пересекается при значениях scale factor 4-5.

Давайте же посмотрим на график.

Данные получились не очень красивыми, но в целом — понятными. Виден провал в районе scale factor 5, а следующий провал в районе scale factor 45. Собственно, две явные ступеньки — выпадание из shared buffers и из дискового кэша.

Параметр shared_buffers отвечает за то, сколько памяти будет использовано PostgreSQL для общего кэша, доступного всем процессам БД. Если какие-то данные попадают в shared buffers, то доступ к ним осуществляется быстрее всего. Более того, все изменения shared buffers происходят с правильными блокировками, поэтому данные там всегда актуальны. По большому счету именно этот большой кэш позволяет БД быстро работать. Более того, в PostgreSQL используется специальный алгоритм, который помогает наиболее часто используемым данным попадать и оставаться в этом кэше.

Следующий уровень — это дисковый кэш операционной системы. Вся свободная память ОС linux используется как дисковый кэш. Конечно, доступ к данным, которые лежат в дисковом кэше будет осуществляться медленнее, чем к тем, что лежат в shared buffers. Но все же это будет происходить достаточно быстро.

Если же данные не были обнаружены в дисковом кэше, то ОС полезет за ними на диск. И это очень-очень долго (конечно, не ясно, что за диски внутри Amazon, но это точно не SSD). Обычный диск может выдать 100-200 случайных операций в секунду (посмотрите калькулятор IOPS), и если количество запросов значительно превышает возможности дисковой подсистемы, то такой режим работы БД обычно называют «у нас легла БД».

Диски являются самым дорогим ресурсом для БД, поэтому их надо экономить и тратить их ресурсы в основном только на запись. Все актуальные данные должны попадать в кэш БД или кэш ОС. Именно поэтому всегда рекомендуют держать для отчетов отдельный сервер БД. Обычно данные, которые нужны для отчетов, не используются на web-сайте. И как только запускается аналитический отчет, он вымывает данные из кэша ОС и БД, и сайт буквально ложится, что мы наблюдали неоднократно у наших клиентов. Конечно, такое происходит только в том случае, если размер БД значительно превышает размер оперативной памяти на сервере.

PS Для любителей PostgreSQL хорошо известный в Ruby-мире Питер Купер выпускает рассылку PostgreSQL Weekly.

• PostgreSQL
• pgbench