Мой сервер базы данных имеет следующий вывод sar для устройства данных:
[postgres@dbsrv07 ~]$ LC_ALL=POSIX sar -d |egrep "await|dev253-2"
00:00:01 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
00:10:01 dev253-2 2721.27 18357.23 20291.52 14.20 613.68 225.51 0.15 40.60
00:20:01 dev253-2 1345.04 574.92 10685.38 8.37 290.65 215.99 0.06 8.61
00:30:01 dev253-2 801.39 193.53 6364.92 8.18 87.49 109.34 0.07 5.95
00:40:01 dev253-2 832.95 195.70 6617.82 8.18 89.30 107.20 0.07 5.87
00:50:01 dev253-2 835.58 162.90 6644.64 8.15 85.35 102.14 0.06 5.24
01:00:01 dev253-2 847.99 232.36 6722.90 8.20 89.91 106.03 0.07 5.64
01:10:01 dev253-2 2240.78 2295.28 17543.52 8.85 163.37 72.91 0.10 23.06
01:20:01 dev253-2 2706.18 1358.97 21482.68 8.44 175.98 65.00 0.08 20.73
01:30:01 dev253-2 5839.31 3292.69 45960.39 8.43 520.98 89.19 0.07 42.24
01:40:01 dev253-2 5221.88 1945.32 41384.97 8.30 553.92 106.05 0.06 33.85
Высокое ожидание сохраняется в течение дня.
Правильно ли я полагаю, что это указывает на узкое место ввода-вывода?
Спасибо
svctm - это мера того, сколько времени потребовалось хранилищу для ответа после того, как команда покинула планировщик ввода-вывода и этот ввод-вывод больше не находился под контролем ядра. Здесь вы видите менее 1 мс, что отлично.
Ждите - это мера того, сколько времени данный ввод-вывод провел во всем планировщике ввода-вывода. Здесь вы видите сотни миллисекунд, что очень плохо. У разных людей / поставщиков разные представления о том, что «хорошо», я бы сказал, что менее 50 мс - это хорошо.
Если бы ваше физическое хранилище было медленным, вы бы увидели большой svctm и большой await. Если IO ядра медленный, вы увидите большое ожидание, но маленькое svctm.
Какой планировщик ввода-вывода вы используете для этого устройства? Учитывая небольшой размер ввода-вывода (8 КБ), вы больше заботитесь о задержке запросов, чем о массовой пропускной способности. Вам, вероятно, будет лучше использовать планировщик крайних сроков, а не планировщик cfq по умолчанию.
Это делается путем помещения лифт = крайний срок в строке ядра в grub.conf и перезагрузке.
Кроме того, учитывая, что у вас есть сотни резервных копий операций ввода-вывода в очереди (avgqu-sz), и вы получаете тысячи IOPS (tps), и я бы предположил, что это ввод-вывод базы данных, который, вероятно, будет директивным, поэтому они не могут быть объединены в более крупные запросы или использовать кеш страниц, вы можете просто слишком многого ожидать от подсистемы хранения.
Из комментария superjami похоже, что у вас есть узкое место «над» диском / массивом. Я бы поинтересовался у сообщества postgres, что они рекомендуют для планирования. В те дни, когда я работал в Solaris, мы бы использовали "черную" таблицу планировщика для машины, которая в первую очередь была ядром базы данных ...
--дэйв
Почти (:-))
await - это комбинация времени обслуживания и времени ожидания (задержки), когда вас действительно беспокоит время ожидания. Если ваше время обслуживания составляет порядка 10 миллисекунд, все замедляется, когда время ожидания равно времени обслуживания.
10 мс - хорошее время обслуживания для дискового массива Sun: я не знаю, какое время подходит для вашего диска, но я вроде как подозреваю, что вы видите узкое место ввода-вывода.
--davecb@spamcop.net