Каковы типичные применения приложений реверс / шаг / преад и pwrite?

Question

Каковы типичные применения приложений реверс / шаг / преад и pwrite?

Если вы нетерпеливы, перейдите к заголовку "ВОПРОС" ниже.

КОНТЕКСТ

Я работаю с Unix(как) системное администрирование и развитие инфраструктуры, но я думаю, что на мой вопрос лучше всего отвечают программисты:o)

Я хочу научиться тестировать файловые системы (простые, управляемые тома, виртуализированные, зашифрованные и т. Д.) С помощью iozone. В качестве упражнения я протестировал USB-накопитель, предназначенный для использования в качестве системного диска в моем слаге ( http://www.nslu2-linux.org/), отформатированном соответственно с помощью vfat, ntfs, ext3, ext4 и xfs. Тест дал некоторые удивительные результаты, которые размещены ниже. Однако причина, по которой меня удивили результаты, может состоять в том, что я все еще новичок в iozone и не знаю, как правильно интерпретировать числа. Отсюда и этот пост.

В моем тесте iozone провела тесты для 11 различных файловых операций, но только для одного размера записи (4 КБ, что соответствует размеру блока всех протестированных файловых систем) и только для одного размера файла (512 МБ). Односторонность размера записи файловой системы и размера файла, конечно, оставляет тест с некоторым смещением. В любом случае, файловые операции перечислены ниже, каждая из которых имеет собственное краткое объяснение:

начальная запись: запись новых данных на диск последовательно, регулярное использование файла
переписать: добавлены новые данные к существующим последовательно, регулярное использование файлов
читать: последовательно читать данные, регулярное использование файла
перечитать: последовательно перечитать данные (проверка буфера или что?)
обратное чтение:???
шагать читать:???
случайное чтение: непоследовательное чтение, обычно использование базы данных
случайная запись: непоследовательная запись, обычно использование базы данных
pread: чтение данных по определенной позиции - для индексации баз данных?
pwrite: запись данных на определенную позицию - для индексации баз данных?
смешанная нагрузка: (очевидно)

Некоторые из этих операций кажутся простыми. Я предполагаю, что начальная запись, перезапись и чтение все используются для регулярной обработки файлов, включая поиск указателя до достижения определенного блока, чтение или запись последовательно (часто через много блоков), иногда из-за фрагментации, иногда приходится немного двигаться вперед. файлы. Единственная цель теста перечитывания (я полагаю) - тестирование буфера. Параллельно случайное чтение / запись - это типичные операции с базой данных, когда указатель должен перемещаться с места на место в одном и том же файле, собирая записи базы данных, например, при соединении таблиц.

ТАК ЧТО ТАКОЕ ВОПРОС?

Все идет нормально. Я был бы очень признателен за любые исправления вышеупомянутых предположений, хотя они кажутся достаточно общеизвестными. Теперь о реальном вопросе: зачем вам когда-нибудь делать обратное чтение? Что такое чтение шага? Мне сказали, что операции "position" pread и pwrite используются с индексированными базами данных, но почему бы просто не сохранить индекс в памяти? Или это то, что происходит на самом деле, и тогда преаду пригодится для перехода к точному местоположению записи, когда задан определенный индекс? Для чего еще вы используете pread / pwrite?

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

БОНУСНЫЙ ВОПРОС

Спросив это, вот бонусный вопрос. Как администратор данной файловой системы, с благодарностью узнав, как интерпретировать тесты моей файловой системы от проницательных программистов;) - есть ли у кого-нибудь предложения о том, как провести анализ фактического использования файловой системы? Экспериментирование с размером записи (блока) в файловой системе тривиально, но требует много времени. Что касается размера и распределения файлов в данной файловой системе, "find" - мой друг. Но что мне делать, чтобы подсчитывать реальные вызовы файловой системы, такие как read(), pwrite() и т. Д.?

Также я был бы очень признателен за любые комментарии о влиянии других ресурсов на результаты тестирования файловой системы, таких как роль процессорной мощности, а также объем и скорость оперативной памяти. Например, какая разница, что я делаю этот тест на машине с процессором Atom 1,66 ГГц и 2 гигабайтами оперативной памяти DDR2, когда я хочу использовать pendrive в слаге с процессором ARM Intel XScale 266 МГц и 32/8 МБ SD/ флэш-ОЗУ?

АРХИТЕКТУРНО РАЗУМНАЯ ДОКУМЕНТАЦИЯ?

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

РЕЗУЛЬТАТЫ ТЕСТА

Правильно. Я обещал результаты моего довольно скромного теста файловой системы с USB-портом. Моим главным ожиданием было, как правило, плохие результаты при записи (поскольку флэш-диск, учитывая его характер, часто имеет больший размер блока, чем фактическая файловая система, управляющая им, а это означает, что для записи небольших изменений необходимо перезаписывать относительно большие объемы неизмененных данных.), и хорошие результаты на чтение. Основными моментами оказались:

Vfat очень хорошо справлялся со всеми операциями, за исключением немного неясного (для меня, во всяком случае) обратного и быстрого чтения. Я предполагаю, что отсутствие функций устраняет большую часть бухгалтерии.
ntfs отстой при операциях перезаписи (добавления) и чтения, что делает его плохим кандидатом для обычной файловой операции. Он также отстой от операции pread, что делает его плохим кандидатом для индексированных баз данных.
удивительно, что ext3 и ext4, последние значительно лучше всех операций, отстой при начальных операциях записи, перезаписи, чтения, произвольной записи и записи, что делает их плохими кандидатами для регулярного использования файлов, а также для интенсивно обновляемых баз данных. Ext4, тем не менее, является мастером случайного чтения и подготовки, что делает его отличным кандидатом на несколько статичных баз данных (?). И ext3, и ext4 высоко оценивают непонятные операции обратного чтения и быстрого чтения, что бы это ни значило.
непревзойденным победителем всех испытаний стал xfs, единственным слабым местом которого является обратное чтение. При первоначальной записи, перезаписи, чтении, произвольной записи и pwrite он является одним из лучших, что делает его отличным кандидатом для регулярного использования файлов, а также для (интенсивно обновляемых) баз данных. При перечитывании, случайном чтении и чтении он входит в число участников, занявших второе место, что делает его хорошим кандидатом для (несколько статичных) баз данных. Это также приносит пользу при быстром чтении - что бы это ни значило!

Любые комментарии по интерпретации этих результатов в основном приветствуются! Номера перечислены ниже (несколько сокращены по соображениям длины), один набор тестов iozone pr. Тип файловой системы, все протестированы на стандартном Pebrive Verbatim 4 ГБ (оранжевого цвета;), пристыкованы к ноутбуку Samsung N105P с процессором Atom N450 1,66 ГГц и 2 ГБ оперативной памяти DDR2 667 МГц с ядром Linux 3.2.0-24 x86 с зашифрованным свопом (да, я знаю, я должен установить 64-битный Linux и оставить своп в открытом виде!).

С уважением, Торстен

PS. После написания этого я обнаружил, что, по-видимому, дистрибутив Debian NSLU2 не поддерживает xfs. Мои вопросы все еще стоят, хотя!

--- vfat ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Mon Jun  4 14:23:57 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /mnt/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000002 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =   12864.82 KB/sec
Parent sees throughput for  1 initial writers   =    3033.39 KB/sec

Children see throughput for  1 rewriters    =   25271.86 KB/sec
Parent sees throughput for  1 rewriters     =    2876.36 KB/sec

Children see throughput for  1 readers      =  685333.00 KB/sec
Parent sees throughput for  1 readers       =  682464.06 KB/sec

Children see throughput for 1 re-readers    =  727929.94 KB/sec
Parent sees throughput for 1 re-readers     =  726612.47 KB/sec

Children see throughput for 1 reverse readers   =  458174.00 KB/sec
Parent sees throughput for 1 reverse readers    =  456910.21 KB/sec

Children see throughput for 1 stride readers    =  351768.00 KB/sec
Parent sees throughput for 1 stride readers     =  351504.09 KB/sec

Children see throughput for 1 random readers    =  553705.94 KB/sec
Parent sees throughput for 1 random readers     =  552630.83 KB/sec

Children see throughput for 1 mixed workload    =  549812.50 KB/sec
Parent sees throughput for 1 mixed workload     =  547645.03 KB/sec

Children see throughput for 1 random writers    =   19958.66 KB/sec
Parent sees throughput for 1 random writers     =    2752.23 KB/sec

Children see throughput for 1 pwrite writers    =   13355.57 KB/sec
Parent sees throughput for 1 pwrite writers     =    3119.04 KB/sec

Children see throughput for 1 pread readers     =  574273.31 KB/sec
Parent sees throughput for 1 pread readers  =  572121.97 KB/sec

--- нтфс ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Mon Jun  4 13:59:37 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /mnt/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000002 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =   11153.75 KB/sec
Parent sees throughput for  1 initial writers   =    2848.69 KB/sec

Children see throughput for  1 rewriters    =    8723.95 KB/sec
Parent sees throughput for  1 rewriters     =    2794.81 KB/sec

Children see throughput for  1 readers      =   24935.60 KB/sec
Parent sees throughput for  1 readers       =   24878.74 KB/sec

Children see throughput for 1 re-readers    =  144415.05 KB/sec
Parent sees throughput for 1 re-readers     =  144340.90 KB/sec

Children see throughput for 1 reverse readers   =   76627.60 KB/sec
Parent sees throughput for 1 reverse readers    =   76362.93 KB/sec

Children see throughput for 1 stride readers    =  367293.25 KB/sec
Parent sees throughput for 1 stride readers     =  366002.25 KB/sec

Children see throughput for 1 random readers    =  505843.41 KB/sec
Parent sees throughput for 1 random readers     =  500556.16 KB/sec

Children see throughput for 1 mixed workload    =  553075.56 KB/sec
Parent sees throughput for 1 mixed workload     =  551754.97 KB/sec

Children see throughput for 1 random writers    =    9747.23 KB/sec
Parent sees throughput for 1 random writers     =    2381.89 KB/sec

Children see throughput for 1 pwrite writers    =   10906.05 KB/sec
Parent sees throughput for 1 pwrite writers     =    1931.43 KB/sec

Children see throughput for 1 pread readers     =   16730.47 KB/sec
Parent sees throughput for 1 pread readers  =   16194.80 KB/sec

--- ext3 ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Sun Jun  3 16:05:27 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /media/verbatim/1/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =    3704.61 KB/sec
Parent sees throughput for  1 initial writers   =    3238.73 KB/sec

Children see throughput for  1 rewriters    =    3693.52 KB/sec
Parent sees throughput for  1 rewriters     =    3291.40 KB/sec

Children see throughput for  1 readers      =  103318.38 KB/sec
Parent sees throughput for  1 readers       =  103210.16 KB/sec

Children see throughput for 1 re-readers    =  908090.88 KB/sec
Parent sees throughput for 1 re-readers     =  906356.05 KB/sec

Children see throughput for 1 reverse readers   =  744801.38 KB/sec
Parent sees throughput for 1 reverse readers    =  743703.54 KB/sec

Children see throughput for 1 stride readers    =  623353.88 KB/sec
Parent sees throughput for 1 stride readers     =  622295.11 KB/sec

Children see throughput for 1 random readers    =  725649.06 KB/sec
Parent sees throughput for 1 random readers     =  723891.82 KB/sec

Children see throughput for 1 mixed workload    =  734631.44 KB/sec
Parent sees throughput for 1 mixed workload     =  733283.36 KB/sec

Children see throughput for 1 random writers    =     177.59 KB/sec
Parent sees throughput for 1 random writers     =     137.83 KB/sec

Children see throughput for 1 pwrite writers    =    2319.47 KB/sec
Parent sees throughput for 1 pwrite writers     =    2200.95 KB/sec

Children see throughput for 1 pread readers     =   13614.82 KB/sec
Parent sees throughput for 1 pread readers  =   13614.45 KB/sec

--- ext4 ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Sun Jun  3 17:59:26 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /media/verbatim/2/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000005 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =    4086.64 KB/sec
Parent sees throughput for  1 initial writers   =    3533.34 KB/sec

Children see throughput for  1 rewriters    =    4039.37 KB/sec
Parent sees throughput for  1 rewriters     =    3409.48 KB/sec

Children see throughput for  1 readers      = 1073806.38 KB/sec
Parent sees throughput for  1 readers       = 1062541.84 KB/sec

Children see throughput for 1 re-readers    =  991162.00 KB/sec
Parent sees throughput for 1 re-readers     =  988426.34 KB/sec

Children see throughput for 1 reverse readers   =  811973.62 KB/sec
Parent sees throughput for 1 reverse readers    =  810333.28 KB/sec

Children see throughput for 1 stride readers    =  779127.19 KB/sec
Parent sees throughput for 1 stride readers     =  777359.89 KB/sec

Children see throughput for 1 random readers    =  796860.56 KB/sec
Parent sees throughput for 1 random readers     =  795138.41 KB/sec

Children see throughput for 1 mixed workload    =  741489.56 KB/sec
Parent sees throughput for 1 mixed workload     =  739544.09 KB/sec

Children see throughput for 1 random writers    =     499.05 KB/sec
Parent sees throughput for 1 random writers     =     399.82 KB/sec

Children see throughput for 1 pwrite writers    =    4092.66 KB/sec
Parent sees throughput for 1 pwrite writers     =    3451.62 KB/sec

Children see throughput for 1 pread readers     =  840101.38 KB/sec
Parent sees throughput for 1 pread readers  =  831083.31 KB/sec

--- xfs ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Mon Jun  4 14:47:49 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /mnt/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000005 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =   21854.47 KB/sec
Parent sees throughput for  1 initial writers   =    3836.32 KB/sec

Children see throughput for  1 rewriters    =   29420.40 KB/sec
Parent sees throughput for  1 rewriters     =    3955.65 KB/sec

Children see throughput for  1 readers      =  624136.75 KB/sec
Parent sees throughput for  1 readers       =  614326.13 KB/sec

Children see throughput for 1 re-readers    =  577542.62 KB/sec
Parent sees throughput for 1 re-readers     =  576533.42 KB/sec

Children see throughput for 1 reverse readers   =  483368.06 KB/sec
Parent sees throughput for 1 reverse readers    =  482598.67 KB/sec

Children see throughput for 1 stride readers    =  537227.12 KB/sec
Parent sees throughput for 1 stride readers     =  536313.77 KB/sec

Children see throughput for 1 random readers    =  525219.19 KB/sec
Parent sees throughput for 1 random readers     =  524062.07 KB/sec

Children see throughput for 1 mixed workload    =  561513.50 KB/sec
Parent sees throughput for 1 mixed workload     =  560142.18 KB/sec

Children see throughput for 1 random writers    =   24118.34 KB/sec
Parent sees throughput for 1 random writers     =    3117.71 KB/sec

Children see throughput for 1 pwrite writers    =   32512.07 KB/sec
Parent sees throughput for 1 pwrite writers     =    3825.54 KB/sec

Children see throughput for 1 pread readers     =  525244.94 KB/sec
Parent sees throughput for 1 pread readers  =  523331.93 KB/sec

3

filesystems benchmarking disk interpretation iozone

Источник

user1435721 05 июн '12 в 13:00

3 ответа

Другие вопросы по тегам filesystems benchmarking disk interpretation iozone

user6188 05 июн '12 в 14:54 2012-06-05 14:54 · Answer 1 · 2012-06-05 14:54

Единственный раз, когда мне нужно было углубиться в производительность файловой системы, я был на системах Windows. Общие принципы применяются независимо от того, какую ОС / файловую систему вы используете...

Зачем вам делать обратное чтение?

Когда программа запускается, она читает блок 987654, а затем, используя эти данные, определяет, что ей нужен блок 123456. Это может произойти при соединении: ваш Db может использовать индекс таблицы table1 для выбора записей (используя индекс) из таблицы два. Операция подбора может происходить в порядке таблицы 1 (обратный порядок таблицы 2).

Подобные ситуации могут происходить при выборе одной таблицы при использовании двух клавиш.

Что такое чтение шага?

Чтение каждого N-го блока отл. блок чтения 12345600, затем блок 12345700, затем блок 12345800 с шагом 100. Представьте таблицу со многими и / или большими столбцами. В этой таблице могут быть строки, в которых требуется несколько блоков файловой системы для хранения данных. Обычно база данных организует эти данные в запись для каждой строки, причем каждая запись занимает несколько последовательных блоков файловой системы. Если ваши строки базы данных занимают 10 блоков файловой системы и вы выбираете два столбца, вам может потребоваться только прочитать 1-й и 6-й блоки этой записи из 10 блоков. Ваш запрос затем должен будет прочитать блок 10001, 10006, 10011, 10016, 10021, 10026 - шаг 5.

Мне сказали, что операции "position" pread и pwrite используются с индексированными базами данных, но почему бы просто не сохранить индекс в памяти?

Размер индекса может превышать разумный объем использования оперативной памяти. Или, ваше предыдущее использование вызывало другие индексы или данные в оперативную память, вызывая извлечение неиспользуемого индекса из кеша файловой системы / базы данных.

Или это то, что происходит на самом деле, и тогда преаду пригодится для перехода к точному местоположению записи, когда задан определенный индекс? Да, это может быть то, что делает ваша база данных.

Для чего еще вы используете pread / pwrite?

Некоторые файлы данных имеют предопределенные "интересные" местоположения. Это может быть корень индекса B-Tree, заголовок таблицы, хвост журнала / журнала или что-то еще, в зависимости от вашей реализации Db. pread/rwrite - это тестирование производительности многократного перехода к заданным определенным местоположениям вместо равномерно случайного сочетания местоположений.

Ссылки?

Существуют системные утилиты для всех основных ОС, которые могут захватывать каждую операцию файловой системы ОС. Я думаю, что они могут быть названы DTRACE или pTAP или pTRACE в *NIX системах. Вы можете использовать горы данных (отфильтрованных интеллектуально) с этих мониторов, чтобы увидеть схему доступа к диску в вашей системе.

Тогда общее практическое правило заключается в том, что для использования БД нецензурные объемы ОЗУ полезны. Тогда все ваши индексы постоянно находятся в оперативной памяти.

user4462 05 июн '12 в 18:39 2012-06-05 18:39 · Answer 2 · 2012-06-05 18:39

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

На мой взгляд, iozone не очень интересный инструмент для бенчмаркинга. И профилирование различных системных вызовов тоже не так интересно, я думаю.

Важно то, как файловая система работает в реальном мире. Однако сравнение с сценариями реального мира может занять очень много времени; например, создание правильной тестовой среды может занять много времени. И именно поэтому инструмент оценки производительности оказывается полезным. Но инструмент тестирования должен уметь работать так, чтобы он был максимально приближен к реальным приложениям; кроме того, обычно неплохо, если инструмент тестирования работает жестко, так что исследуются пределы задействованного аппаратного / программного обеспечения.

Два эталонных инструмента, удовлетворяющих этим требованиям, - это fio и Oracle. С обоими инструментами относительно легко определить эталонный тест, который будет использовать разумное сочетание операций чтения и записи, и указать, насколько параллельный эталонный тест должен выполняться. И можно выполнять тесты как на уровне устройства, так и на уровне FS; Это хорошо, потому что иногда вы хотите протестировать оборудование для хранения без нагрузки на конкретную файловую систему. По сравнению с Орионом, у fio есть преимущество динамического списка рассылки, где очень хорошие возможности для хороших ответов (я не нашел список рассылки для Ориона).

user2980438 02 ноя '15 в 19:42 2015-11-02 19:42 · Answer 3 · 2015-11-02 19:42

Я могу предоставить некоторые сведения по двум частям вашего вопроса. Тест "обратное чтение" был введен в результате наблюдения за поведением ввода / вывода некоторых приложений машиностроения. Эти приложения часто читают с диска последовательно вперед и затем назад. Было предположение, что это было связано с (линейной алгеброй) прямой и обратной заменой или что это было связано с оригинальными реализациями, которые полагались на накопители на магнитной ленте.

Что касается быстрого доступа, это была обычная схема ввода / вывода для многих приложений сейсмической разведки (глубинная и / или временная миграция IIRC). Как и в случае со сценарием "обратное чтение", это также было введено после наблюдения за поведением ввода / вывода этих приложений.