java самый быстрый параллельный случайный метод чтения/записи файлов для твердотельных накопителей без подкачки памяти

У меня есть Linux-бокс с 32 ГБ ОЗУ и набором из 4 SSD в конфигурации рейда 0, максимальная пропускная способность которого составляет около 1 ГБ (случайное чтение 4k), и я пытаюсь определить лучший способ доступа к файлам на них случайным образом и одновременно используя Яву. Два основных способа, которые я видел до сих пор, — это файл с произвольным доступом и сопоставленные буферы прямого байта.

Вот где это становится сложным, хотя. У меня есть собственный кеш памяти для объектов, поэтому любой вызов объектов, хранящихся в файле, должен проходить на диск, а не в выгружаемую память (я отключил пространство подкачки в своем Linux-боксе, чтобы предотвратить это). В то время как отображенные буферы прямой памяти предположительно являются самыми быстрыми, они полагаются на подкачку, что нехорошо, потому что A) я использую всю свободную память для кеша объектов, вместо этого использование сопоставленных байтовых буферов повлекло бы за собой огромные накладные расходы на сериализацию, для чего предназначен кеш объектов предотвратить. (Моя программа уже ограничена ЦП) B) с mappedbytebuffers ОС обрабатывает детали того, когда данные записываются на диск, мне нужно контролировать это самостоятельно, т.е. когда я пишу (байт []), он сразу же отправляется на диск, это предотвращает повреждение данных в случае сбоя питания, поскольку я не использую транзакции ACID.

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

Наконец, у меня не может быть ситуации, когда я создаю новые объекты byte[] для чтения или записи, это потому, что я выполняю почти 100000 операций чтения/записи в секунду, выделение и сбор мусора всех этих объектов убили бы мою программу, что время чувствительный и уже ограниченный ЦП, повторное использование объектов byte[] нормально.

Пожалуйста, не предлагайте какое-либо программное обеспечение для БД, поскольку я пробовал большинство из них, и они значительно усложняют и нагружают процессор.

У кого-нибудь была такая дилемма?


person user1467885    schedule 14.02.2013    source источник
comment
Мне кажется, вам нужно больше физических ящиков. Если вы уже максимально используете пропускную способность ЦП, ОЗУ и SSD, не похоже, что вы можете получить гораздо больше из коробки, которая у вас есть.   -  person Sten Petrov    schedule 14.02.2013
comment
MappedByteBuffer.force() может принудительно сбросить обновленные данные в файл на диске.   -  person horaceman    schedule 09.04.2013


Ответы (2)


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

Нет, если у вас достаточно оперативной памяти. Отображение связывает страницы в памяти со страницами на диске. Если ОС не решит, что ей нужно восстановить оперативную память, страницы не будут заменены. А если у вас не хватает оперативной памяти, то отключение подкачки приведет к фатальной ошибке, а не к снижению производительности.

Я использую всю свободную память для кеша объектов

Если ваши объекты не очень долговечны, это плохая идея, потому что сборщику мусора придется выполнять много работы во время работы. Вы часто обнаружите, что меньший размер кэша приводит к более высокой общей пропускной способности.

с mappedbytebuffers ОС обрабатывает детали того, когда данные записываются на диск, мне нужно контролировать это самостоятельно, т.е. когда я пишу (байт []), он сразу же попадает на диск

На самом деле это не так, если только вы не смонтировали файловую систему с параметром sync. И тогда вы все равно рискуете потерять данные с вышедшего из строя диска (особенно в RAID 0).

Я не уверен, как я могу это сделать без mappedbytebuffers

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

Я не использую транзакции ACID

Тогда я думаю, что данные не так уж и ценны. Так что перестаньте беспокоиться о возможности того, что кто-то споткнется о шнур питания.

person parsifal    schedule 14.02.2013

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

Если буферы отображаемых байтов не обеспечивают необходимой вам производительности, вам, возможно, придется обойти файловую систему и записать непосредственно в необработанные разделы (что и делает СУБД). Для этого вам, вероятно, потребуется написать код C++ для обработки ваших данных и получить к нему доступ через JNI.

person antlersoft    schedule 14.02.2013