У нас возникла проблема, когда один из наших Linux-серверов (Ubuntu 10.04 LTS, работающий на EC2 с четырехкратным размером, 68 ГБ ОЗУ и 8 виртуальных ядер с частотой 3,25 ГГц каждое) зависает каждые несколько секунд. Ввод ssh-сеанса зависнет, а запуск strace в одном из запущенных процессов Postgresql обычно показывает:
02:37:41.567990 semop(7831581, {{3, -1, 0}}, 1
за несколько секунд, прежде чем он продолжится (он всегда застревает в этом семопе).
OProfile показывает, что большая часть времени проводится в ядре (60%) по сравнению с 37% в Postgresql.
Результатом этих остановок (которые внезапно начались день назад) является то, что нагрузка на бокс снизилась с 0,7 до 10+, что приводит к замедлению работы всего нашего стека.
Есть идеи, как отследить, что происходит? iostat не показывает, что диски особенно медленные или перегруженные, а вверху показывает скачок% процессора пользователя с 8% до примерно 40% всякий раз, когда происходит такое резервное копирование.
Я подозреваю, что в вашей системе заканчиваются семафоры. Проверьте ipcs -l для текущих настроек. Вот некоторая информация о настройке семафоров для postgresql. В частности, я бы попытался увеличить максимальное количество семафоров в масштабе всей системы (SEMMNS) и максимальное количество семафоров в наборе (SEMMSL). Ты можешь использовать sysctl -p чтобы изменить эти настройки.
Наконец, мы отследили это до параметра PostgreSQL: «work_mem», который устанавливает, сколько оперативной памяти получает каждый процесс Postgres для выполнения своих задач. Мы вышли из (крошечного) значения по умолчанию, из-за которого система попала в диск, что является поцелуем смерти на EC2 (и внезапный всплеск активности диска приводил к зависанию ядра в быстрых всплесках iowait).
Поскольку вы уже обнаружили большую часть времени, проведенного в ядре, я бы предложил включить CONFIG_LATENCYTOP и запустить, ну, latencytop чтобы увидеть больше. Можно сделать с oprofileтоже но latencytop намного удобнее.
Взгляните на этот вопрос Linux с 256 ГБ памяти / 48 ядер - машина начинает работать / задыхаться, когда осталось тонны памяти и посмотрите, поможет ли ссылка о mysql и безумие подкачки с большой памятью.
Принимая во внимание «68 ГБ ОЗУ», я подозреваю, что это связано с неэффективностью виртуальной машины. Вы пробовали перезапустить Postgresql или перезагрузиться?
Мы столкнулись с аналогичной проблемой (отличающейся тем, что паузы разделялись минутами), когда впервые развернули наши серверы Oracle на серверах с 96 ГБ памяти. В итоге мы отследили его до процесса ядра, отвечающего за определение памяти, которая может быть выгружена. Настройка процесса на более частую проверку более мелких фрагментов решила проблему.
Когда это происходит, проверьте доступную энтропию:
cat / proc / sys / ядро / случайный / entropy_avail
У Ubuntu, похоже, есть дурная привычка требовать от системы реальные случайные числа, когда в этом нет необходимости, что может вызвать подобные ситуации. Попробуйте заставить аппаратный генератор случайных чисел работать, он решит проблемы, если они у вас есть.