Вот часть моего журнала контрольных точек:
2014-03-26 11:51:29.341 CDT,,,18682,,532854fc.48fa,4985,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 15047 buffers (1.4%); 0 transaction log file(s) added, 0 removed, 30 recycled; write=68.980 s, sync=1.542 s, total=70.548 s; sync files=925, longest=0.216 s, average=0.001 s",,,,,,,,,""
2014-03-26 11:56:05.430 CDT,,,18682,,532854fc.48fa,4987,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 16774 buffers (1.6%); 0 transaction log file(s) added, 0 removed, 31 recycled; write=72.542 s, sync=17.164 s, total=89.733 s; sync files=885, longest=3.812 s, average=0.019 s",,,,,,,,,""
2014-03-26 12:01:21.650 CDT,,,18682,,532854fc.48fa,4989,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 14436 buffers (1.4%); 0 transaction log file(s) added, 0 removed, 33 recycled; write=122.350 s, sync=5.212 s, total=127.676 s; sync files=924, longest=3.740 s, average=0.005 s",,,,,,,,,""
2014-03-26 12:06:25.028 CDT,,,18682,,532854fc.48fa,4991,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 13277 buffers (1.3%); 0 transaction log file(s) added, 0 removed, 29 recycled; write=126.217 s, sync=5.733 s, total=131.991 s; sync files=894, longest=1.859 s, average=0.006 s",,,,,,,,,""
2014-03-26 12:10:41.958 CDT,,,18682,,532854fc.48fa,4993,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 20765 buffers (2.0%); 0 transaction log file(s) added, 0 removed, 28 recycled; write=88.015 s, sync=10.818 s, total=98.872 s; sync files=881, longest=2.690 s, average=0.012 s",,,,,,,,,""Я заметил, что иногда наша база данных работает очень медленно - вы можете увидеть очень большое количество обычно коротких запросов, которые зависают гораздо дольше, чем сейчас. Это происходит регулярно без явного виновника.
Вопрос: Может ли контрольно-пропускной пункт вызвать это? Что происходит на этапе синхронизации контрольной точки?
postgresql
Конрад Гарус
источник
источник
Сброс грязных буферов файловой системы ОС, вызванных превышением
dirty_bytesилиdirty_ratioявляется операцией блокировки переднего плана!В ядре параметров настройки
dirty_bytes,dirty_background_bytes,dirty_ratio,dirty_background_ratioиdirty_centisecsконтроль смыв грязных файловой системы ОС буферов на диск.dirty_bytesэто порог в байтах,dirty_ratioэто порог как отношение общего объема памяти.dirty_background_bytesиdirty_background_ratioявляются аналогичными пороговыми значениями, но сброс происходит в фоновом режиме и не блокирует другие операции чтения / записи, пока не завершится.dirty_centisecsсколько секунд может пройти до начала сброса.Недавно значения по умолчанию для этих настраиваемых параметров были уменьшены в Linux, поскольку объем памяти для современных машин значительно увеличился. Даже соотношения 5 и 10% для
dirty_background_ratioиdirty_ratioна машине 256GB может залить систему ввода / вывода.Настроить
dirty_background_bytesилиdirty_background_ratioначать сбрасывать грязные буферы в фоновом режиме сложно. К счастью, вы можете настроить эти параметры без необходимости останавливать PostgreSQL или хост, передавая новые значения в соответствующие файлы:например, чтобы установить количество байтов, для которых выполняется очистка фона. Если вы используете RAID-карту с резервным питанием от батареи, конденсатора или флэш-памяти (вы не хотите хранить свои данные в случае сбоя, не так ли?), Начните с настройки
dirty_background_bytesна 1/2 размера буфера кэша записи иdirty_bytes3/4 этого размера. Контролируйте свой профиль ввода / вывода с помощью iostats, и если вы все еще видите проблемы с задержкой, это означает, что загрузка записи в базу данных все еще превышает загрузку кеша буферов файлов. Уменьшайте значения до тех пор, пока не улучшится задержка, или рассмотрите возможность обновления подсистемы ввода-вывода. Платы FusionIO и твердотельные накопители - это две возможности для максимальной пропускной способности ввода-вывода.Удачи!
источник