Ограничьте фоновый сброс Linux (грязные страницы)

После большого сравнительного тестирования с sysbench я прихожу к этому заключению:

Выжить (мудрый производительностью) ситуация где

• злой процесс копии лавинно рассылает грязные страницы
• и аппаратный кэш записи присутствует (возможно также без этого)
• и синхронные чтения или записи в секунду (IOPS) очень важны

просто выведите все лифты, очереди и кэши грязной страницы. Корректное место для грязных страниц находится в RAM того аппаратного кэша записи.

Скорректируйте dirty_ratio (или новый dirty_bytes) как низко как возможный, но следите за последовательной пропускной способностью. В моем особом случае 15 МБ были оптимальны (echo 15000000 > dirty_bytes).

Это - больше взлом, чем решение, потому что гигабайты RAM теперь используются для чтения, кэширующегося только вместо грязного кэша. Чтобы грязный кэш удался хорошо в этой ситуации, фоновый ассенизатор ядра 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 test_file.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 ГБ dirty_bytes:

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

- file-block-size=4096 с 15 МБ dirty_bytes:

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 МБ dirty_bytes в неактивной системе:

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 гибибайт RAM 1 066 МГц
• Материнская плата Супермикро X8DTN (5 520 чипсетов)
• 12 дисков Барракуды Seagate 1 ТБ
  • 10 в программном обеспечении RAID 10 Linux
• Ядро 2.6.32
• Файловая система xfs
• Нестабильный Debian

Таким образом, я теперь уверен, что эта конфигурация будет работать хорошо в неактивной, высокой загрузке и даже ситуациях с предельной нагрузкой для трафика базы данных, который иначе оголодал бы последовательным трафиком. Последовательная пропускная способность выше, чем ссылки на два гигабита могут поставить так или иначе, таким образом, без проблем, уменьшающая ее немного.