Після багатьох тестів із системою sysbench я приходжу до такого висновку:
Щоб вижити (у перформансі) ситуацію, коли
- злий процес копіювання заливає брудні сторінки
- і кеш-пам'ять кеш-пам'яті присутня (можливо, і без цього)
- а синхронне читання або запис в секунду (IOPS) є критичним
просто скиньте всі ліфти, черги та брудні кеші сторінок. Правильне місце для брудних сторінок знаходиться в оперативній пам’яті цього кеш-пам'яті запису.
Налаштуйте брудний коефіцієнт (або нові брудні байти) якомога менше, але слідкуйте за послідовністю пропускної здатності. У моєму конкретному випадку 15 Мб були оптимальними ( echo 15000000 > dirty_bytes).
Це скоріше хак, ніж рішення, оскільки гігабайти оперативної пам’яті зараз використовуються для кешування читання лише замість брудного кешу. Щоб брудний кеш добре працював у цій ситуації, флеш-фоновому режиму ядра Linux потрібно було б середньо оцінити, з якою швидкістю базовий пристрій приймає запити та відповідно налаштовує промивання фону. Нелегко.
Технічні характеристики та орієнтири для порівняння:
Перевірений під час ddнулів на диску, sysbench показав величезний успіх , збільшивши 10 ниток fsync , записуючи на 16 кБ від 33 до 700 IOPS (ліміт холостого ходу: 1500 IOPS) та одиночний потік від 8 до 400 IOPS.
Без навантаження IOPS не впливали (~ 1500) і пропускна здатність трохи зменшувалася (з 251 Мб / с до 216 Мб / с).
dd дзвінок:
dd if=/dev/zero of=dumpfile bs=1024 count=20485672
для sysbench, тестовий файл.0 був підготовлений до розбору:
dd if=/dev/zero of=test_file.0 bs=1024 count=10485672
sysbench виклик для 10 потоків:
sysbench --test=fileio --file-num=1 --num-threads=10 --file-total-size=10G --file-fsync-all=on --file-test-mode=rndwr --max-time=30 --file-block-size=16384 --max-requests=0 run
виклик sysbench для одного потоку:
sysbench --test=fileio --file-num=1 --num-threads=1 --file-total-size=10G --file-fsync-all=on --file-test-mode=rndwr --max-time=30 --file-block-size=16384 --max-requests=0 run
Менші розміри блоків показали ще більш різкі цифри.
--file-block-size = 4096 з 1 Гб брудних байтів:
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 1
Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.
Operations performed: 0 Read, 30 Write, 30 Other = 60 Total
Read 0b Written 120Kb Total transferred 120Kb (3.939Kb/sec)
0.98 Requests/sec executed
Test execution summary:
total time: 30.4642s
total number of events: 30
total time taken by event execution: 30.4639
per-request statistics:
min: 94.36ms
avg: 1015.46ms
max: 1591.95ms
approx. 95 percentile: 1591.30ms
Threads fairness:
events (avg/stddev): 30.0000/0.00
execution time (avg/stddev): 30.4639/0.00
--файл-блок-розмір = 4096 з 15 Мб брудних байтів:
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 1
Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.
Operations performed: 0 Read, 13524 Write, 13524 Other = 27048 Total
Read 0b Written 52.828Mb Total transferred 52.828Mb (1.7608Mb/sec)
450.75 Requests/sec executed
Test execution summary:
total time: 30.0032s
total number of events: 13524
total time taken by event execution: 29.9921
per-request statistics:
min: 0.10ms
avg: 2.22ms
max: 145.75ms
approx. 95 percentile: 12.35ms
Threads fairness:
events (avg/stddev): 13524.0000/0.00
execution time (avg/stddev): 29.9921/0.00
--file-block-size = 4096 з 15 Мб брудних байтів в режимі очікування:
sysbench 0.4.12: багатопотокова система оцінки системи
Running the test with following options:
Number of threads: 1
Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.
Operations performed: 0 Read, 43801 Write, 43801 Other = 87602 Total
Read 0b Written 171.1Mb Total transferred 171.1Mb (5.7032Mb/sec)
1460.02 Requests/sec executed
Test execution summary:
total time: 30.0004s
total number of events: 43801
total time taken by event execution: 29.9662
per-request statistics:
min: 0.10ms
avg: 0.68ms
max: 275.50ms
approx. 95 percentile: 3.28ms
Threads fairness:
events (avg/stddev): 43801.0000/0.00
execution time (avg/stddev): 29.9662/0.00
Тест-система:
- Adaptec 5405Z (це кеш-пам'ять запису 512 Мб із захистом)
- Intel Xeon L5520
- 6 ГБ оперативної пам'яті при 1066 МГц
- Материнська плата Supermicro X8DTN (чіпсет 5520)
- 12 дисків Seagate Barracuda 1 TB
- 10 у програмі Linux RAID 10
- Ядро 2.6.32
- Файлова система xfs
- Debian нестабільний
Підсумовуючи це, я впевнений, що ця конфігурація буде добре працювати в режимі очікування, з високим навантаженням і навіть з повним навантаженням для трафіку баз даних, які в іншому випадку були б голодними від послідовного руху. Послідовна пропускна здатність вище двох гігабітних посилань здатна доставити в будь-якому випадку, тому немає проблем трохи зменшити її.