Влияние буферного кэша Linux на IO пишет? - PullRequest
Новая
       23

Влияние буферного кэша Linux на IO пишет?

1 голос
/ 22 февраля 2011

Я копирую большие файлы (3 x 30 ГБ) между двумя файловыми системами на сервере Linux (ядро 2.6.37, 16 ядер, 32 ГБ ОЗУ), и у меня низкая производительность. Я подозреваю, что использование буферного кеша снижает производительность ввода-вывода.

Я написал небольшую программу на C, чтобы воспроизвести проблему. Программа записывает 20G нулевых байтов непосредственно на диск SAS (/ dev / sda, без файловой системы). Он также поддерживает флаг O_DIRECT.

Когда я запускаю программу с O_DIRECT, я получаю очень стабильную и предсказуемую производительность: 

/dev/sda:   100M current_rate=195.569950M/s avg_rate=195.569950M/s  
/dev/sda:   200M current_rate=197.063362M/s avg_rate=196.313815M/s  
/dev/sda:   300M current_rate=200.479145M/s avg_rate=197.682893M/s  
/dev/sda:   400M current_rate=210.400076M/s avg_rate=200.715853M/s  
...  
/dev/sda: 20100M current_rate=206.102701M/s avg_rate=201.217154M/s  
/dev/sda: 20200M current_rate=206.485716M/s avg_rate=201.242573M/s  
/dev/sda: 20300M current_rate=197.683935M/s avg_rate=201.224729M/s  
/dev/sda: 20400M current_rate=200.772976M/s avg_rate=201.222510M/s

Без O_DIRECT это отдельная история: 

/dev/sda:   100M current_rate=1323.171377M/s avg_rate=1323.171377M/s  
/dev/sda:   200M current_rate=1348.181303M/s avg_rate=1335.559265M/s  
/dev/sda:   300M current_rate=1351.223533M/s avg_rate=1340.740178M/s  
/dev/sda:   400M current_rate=1349.564091M/s avg_rate=1342.935321M/s  
...  
/dev/sda: 20100M current_rate=67.203804M/s avg_rate=90.685743M/s  
/dev/sda: 20200M current_rate=68.259013M/s avg_rate=90.538482M/s  
/dev/sda: 20300M current_rate=64.882401M/s avg_rate=90.362464M/s  
/dev/sda: 20400M current_rate=65.412577M/s avg_rate=90.193827M/s

Я понимаю, что первоначальная пропускная способность высока, потому что эти данные кэшируются и записываются на диск. Однако я не ожидаю, что общая производительность при использовании буферного кэша будет на 50% меньше, чем при использовании O_DIRECT.

Я также делал тесты с dd, я получаю аналогичные результаты (я использовал 10G, хотя здесь вместо 20G): 

$ dd if=/dev/zero of=/dev/sdb bs=32K count=327680 oflag=direct
327680+0 records in
327680+0 records out
10737418240 bytes (11 GB) copied, 54.0547 s, 199 MB/s

$ dd if=/dev/zero of=/dev/sdb bs=32K count=327680             
327680+0 records in
327680+0 records out
10737418240 bytes (11 GB) copied, 116.993 s, 91.8 MB/s

Существуют ли какие-либо настройки ядра, которые могут решить / минимизировать проблему?

1 Ответ

1 голос
/ 22 февраля 2011

Буферный кэш достаточно эффективен, даже при буферизации огромных объемов данных.

Запустив тест dd на твердотельном накопителе предприятия, я могу легко выполнить более 1 ГБ / с записи по 32 КБ через буферный кеш.

Мне интересны ваши результаты, но я не думаю, что ваша проблема в том, что "буферный кеш слишком медленный".

Мой первый вопрос: медленно ли это, потому что у вас ограниченный процессор или диск? Проверьте, не привязано ли одно ядро ​​ЦП на 100% во время теста - это может указывать на то, что что-то не так на уровне драйвера или блока, например лифт ввода-вывода, который ведет себя неправильно. Если вы обнаружили привязку ядра, запустите несколько профилей, чтобы узнать, что это за ядро.

Если вы ограничены диском, вы можете исследовать, как выглядят операции ввода-вывода на уровне устройства (используйте blktrace?), И посмотреть, сможете ли вы выяснить, дает ли получающийся шаблон ввода-вывода низкую производительность на уровень устройства.

Кроме того, вы, возможно, захотите использовать что-то вроде fio для запуска своих тестов, вместо того, чтобы изобретать свою собственную программу тестирования производительности - другим будет проще воспроизвести ваши результаты, и вы уверены, что ваша программа не виновата. .

...