Недавно я заметил очень ужасное падение производительности блокировки PostgreSQL после запуска сервера БД в течение пары месяцев. За эти недели нагрузка на сайт сильно выросла, но скорость падает.
$ psql webspace2_db
psql (9.0.1)
Type "help" for help.
webspace2_db=#
На сервере БД работает FreeBSD 8.1 + PostgreSQL 9.0.1
FreeBSD Moncalvo 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #1: Mon Jan 10 13:02:48 MYT 2011 hailang@Moncalve:/usr/obj/usr/src/sys/Moncalve amd64
Общий объем памяти на сервере составляет 4 ГБ.
Moncalvo# cat /var/run/dmesg.boot | grep memory
real memory = 4294967296 (4096 MB)
avail memory = 4101955584 (3911 MB)
В конфигурации ядра выделено всего 3 ГБ общей памяти.
# Shared Memory
options SEMMNI=256
options SEMMSL=128
options SEMMNS=32768
options SEMMAP=512
options SEMMNU=256
options SEMOPM=128
options SHMMNI=512
options SHMSEG=256
options SHMMAX=3221225472
options SHMALL=3221225472
options SHMMAXPGS=786432
Это ключевые настройки postgresql.conf
Moncalvo# cat postgresql.conf | grep shared_buffers
shared_buffers = 512MB # min 128kB
Moncalvo# cat postgresql.conf | grep effective_cache_size
effective_cache_size = 3276MB
Moncalvo# cat postgresql.conf | grep work_mem
work_mem = 256MB # min 64kB
maintenance_work_mem = 128MB # min 1MB
По словам пользователей, в наши дни веб-сайт становится все медленнее и медленнее, я много настраивал веб-службы на другом сервере, но без эффективного повышения производительности, поэтому я думаю, что, возможно, проблема связана с сервером БД. Итак, я зарегистрировал медленные запросы и обнаружил, что большинство из них имеют механизм блокировки, а часть затрачиваемого времени ужасна.
LOG: duration: 4768697.255 ms statement: SELECT pg_advisory_lock(93690)
LOG: duration: 4739020.976 ms statement: SELECT pg_advisory_lock(93690)
LOG: duration: 4709376.119 ms statement: SELECT pg_advisory_lock(93690)
LOG: duration: 4679438.894 ms statement: SELECT pg_advisory_lock(93690)
LOG: duration: 4649714.811 ms statement: SELECT pg_advisory_lock(93690)
LOG: duration: 4619931.184 ms statement: SELECT pg_advisory_lock(93690)
LOG: duration: 4590323.188 ms statement: SELECT pg_advisory_lock(93690)
LOG: duration: 4560627.214 ms statement: SELECT pg_advisory_lock(93690)
LOG: duration: 4530796.297 ms statement: SELECT pg_advisory_lock(93690)
LOG: duration: 4501178.286 ms statement: SELECT pg_advisory_lock(93690)
LOG: duration: 4471515.579 ms statement: SELECT pg_advisory_lock(93690)
LOG: duration: 4441832.934 ms statement: SELECT pg_advisory_lock(93690)
LOG: duration: 4410774.012 ms statement: SELECT pg_advisory_lock(93690)
LOG: duration: 4382435.595 ms statement: SELECT pg_advisory_lock(93690)
Любая помощь и предложение приветствуются.
Я не специалист по БД, но похоже на недопустимое использование Консультативные блокировки где-нибудь в вашем приложении.
PostgreSQL предоставляет средства для создания блокировок, которые имеют значение, определяемое приложением. Они называются рекомендательными блокировками, потому что система не требует их использования - это зависит от приложения, чтобы использовать их правильно.
и
Как и все блокировки в PostgreSQL, полный список рекомендательных блокировок, удерживаемых в настоящее время любым сеансом, можно найти в pg_locks системный вид.
Редактировать:
Заглядывая в настроение исходный код, /moodle/lib/dml/pgsql_native_moodle_database.php Я только что нашел кое-что, что мощь быть интересным:
public function get_session_lock($rowid) {
// NOTE: there is a potential locking problem for database running
// multiple instances of moodle, we could try to use
// pg_advisory_lock(int, int), luckily there is not a big chance
// that they would collide
if (!$this->session_lock_supported()) {
return;
}
parent::get_session_lock($rowid);
$sql = "SELECT pg_advisory_lock($rowid)";
...
}