Linux/perl mmap performance

Question

Я пытаюсь оптимизировать обработку больших наборов данных с помощью mmap. Набор данных находится в диапазоне гигабайт. Идея состояла в том, чтобы объединить весь файл в память, позволяя нескольким процессам работать в наборе данных одновременно (только для чтения). Однако он работает не так, как ожидалось.

Как простой тест, я просто mmap файл (используя модуль Sys :: Mmap perl, используя субмат «mmap», который, как я полагаю, непосредственно отображает базовую функцию C) и имеет процесс сна. При этом код тратит более минуты, прежде чем он вернется из вызова mmap, несмотря на то, что этот тест ничего не делает - даже чтение - из файла mmap'ed.

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

Удовлетворительно, кажется, что второй процесс также проводит много времени, прежде чем вернуться из вызова mmap, примерно в то же время, что и mmap'ing файла в первый раз.

Я убедился, что MAP_SHARED используется и что процесс, который отображает файл в первый раз, все еще активен (что он не был завершен и что mmap не был удален).

Я ожидал, что mmapped-файл позволит мне дать нескольким рабочим процессам эффективный случайный доступ к большому файлу, но если каждый вызов mmap требует сначала прочитать весь файл, это немного сложнее. Я не тестировал длительные процессы, чтобы убедиться, что быстрый доступ после первой задержки, но я ожидал использования MAP_SHARED, и достаточно другого отдельного процесса.

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

Любая идея, что я делаю неправильно, или если я полностью неправильно понял, как должен работать mmap?

Answer 1

Хорошо, нашел проблему. Как подозревали, ни linux, ни perl не виноваты. Для того, чтобы открыть и получить доступ к файлу я сделать что-то вроде этого:

#!/usr/bin/perl 
# Create 1 GB file if you do not have one: 
# dd if=/dev/urandom of=test.bin bs=1048576 count=1000 
use strict; use warnings; 
use Sys::Mmap; 

open (my $fh, "<test.bin") 
    || die "open: $!"; 

my $t = time; 
print STDERR "mmapping.. "; 
mmap (my $mh, 0, PROT_READ, MAP_SHARED, $fh) 
    || die "mmap: $!"; 
my $str = unpack ("A1024", substr ($mh, 0, 1024)); 
print STDERR " ", time-$t, " seconds\nsleeping.."; 

sleep (60*60); 

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

Ошибка в том, что я в своем коде обработал скаляр $mh как ручку, что-то легкое и легко перемещается (читайте: pass by value). Оказывается, на самом деле это длинная строка в формате GB, окончательно не то, что вы хотите перемещать, не создавая явной ссылки (perl lingua для значения «указатель»/дескриптор).Поэтому, если вам нужно хранить в хеше или аналогичном, убедитесь, что вы храните \$mh, и разрешите его, когда вам нужно использовать его, как ${$hash->{mh}}, обычно как первый параметр в подстроке или аналогичный.

Answer 2

Это звучит удивительно. Почему бы не попробовать чистую версию C?

Попробуйте код на другой версии ОС/perl.

Answer 3

Если у вас относительно новая версия Perl, вы не должны использовать Sys :: Mmap. Вы должны использовать слой PerlIO mmap.

Можете ли вы разместить код, который используете?

Answer 4

В 32-разрядных системах адресное пространство, для которого требуется mmap() s, является довольно ограниченным (и варьируется от OS до OS). Помните об этом, если вы используете файлы с несколькими гигабайтами, а вы только тестируете 64-битную систему. (Я бы предпочел написать это в комментарии, но у меня пока недостаточно очков репутации)

Answer 5

См. Wide Finder для производительности perl с mmap. Но есть одна большая ловушка. Если ваш набор данных будет на классическом HD и вы будете читать из нескольких процессов, вы можете легко попасть в произвольный доступ, и ваш IO упадет до неприемлемых значений (20-40 раз).

Answer 6

Одна вещь, которая может помочь исполнению, - использование «madvise (2)». возможно, наиболее легко сделано через Inline :: C. «madvise» позволяет вам указать ядру, как будет выглядеть ваш шаблон доступа (например, последовательный, случайный и т. д.).

Answer 7

Хорошо, вот еще одно обновление. Использование атрибута Sys :: Mmap или PerlIO «: mmap» отлично работает в perl, но только до 2 ГБ файлов (малый 32-разрядный предел). После того, как файл превышает 2 ГБ, появляются следующие проблемы:

Использование Sys :: Mmap и substr для доступа к файлу, кажется, что substr принимает только 32-битный int для параметра позиции даже в системах, где perl поддерживает 64 бит. Там, по крайней мере одна ошибка писал об этом:

#62646: Maximum string length with substr

Использование open(my $fh, "<:mmap", "bigfile.bin") после того, как файл больше 2 ГБ, кажется, Perl либо повесить/или настаивать на чтение всего файла на первом чтении (не уверенный, что, я никогда не запускал его достаточно долго, чтобы убедиться, что он завершен), что приводит к мертвой медленной производительности.

Я не нашел никакого обходного пути ни для одного из них, и в настоящее время я застрял в медленных файлах (без mmap'ed) для работы над этими файлами. Если я не найду обходной путь, мне, возможно, придется реализовать обработку на C или другом языке более высокого уровня, который лучше поддерживает mmap'ing огромные файлы.

Answer 8

Если я могу подключить свой собственный модуль: я бы советовал использовать File::Map вместо Sys::Mmap. Это намного проще в использовании и меньше подвержено сбою, чем Sys :: Mmap.

Answer 9

Ваш доступ к этому файлу должен быть хорошо случайным, чтобы оправдать полный mmap. Если ваше использование распределено неравномерно, вам, вероятно, лучше прибегнуть к поиску, прочитать в свежеразделенной области и обработать это, бесплатно, полоскать и повторить. И работать с кусками кратных 4k, скажем, 64k или около того.

Я когда-то сравнивал алгоритмы сопоставления строк с множеством строк. mmaping весь файл был медленным и бессмысленным. Чтение в статический буфер 32kish было лучше, но все же не особенно хорошо. Чтение свежеиспеченного фрагмента, обработка которого и последующее его разрешение позволяют ядру творить чудеса под капотом. Разница в скорости была огромная, но с другой стороны, сопоставление образцов очень быстрая, и больше внимания следует уделять эффективности обработки, чем обычно требуется.