Cassandra с JNA работает медленно (высокий IO)

Question

мы используем Cassandra 2.0.14 в системе с 64 ГБ оперативной памяти, объемом 8 ГБ HEAP, 32-ядерным процессором, Java 1.7. Когда загружается JNA (как рекомендовано в производственных настройках), это отрицательно влияет на производительность, особенно при использовании с HDD => это значительно увеличивает ожидания ввода-вывода. Похоже, что JNA отлично работает только при использовании в сочетании с диском SSD. В противном случае лучше не использовать JNA вообще.

Мои вопросы:

Имеет кто-то подобный опыт? Как возможно, что Java превзойдет собственные операции с файловой системой (доступ через JNA)?

Можем ли мы использовать Cassandra без JNA для использования в производстве? Есть ли побочные эффекты?

Результаты (упорядоченные по производительности):

а) HDD + ЮНА Худшая производительность. Высокий уровень ожидания.

b) HDD, нет JNA Хорошая производительность. Low IO ждать, но использование процессора Cassandra довольно высока (500%)

с) SSD + ЮНА Кажется, чтобы обеспечить наилучшую производительность. Низкий уровень ожидания. Низкое потребление CPU Cassandra (300%). Но мы не всегда можем использовать SSD. Это было скорее испытание, это не решение для меня.

спасибо.

Answer 1

Afaik, Cassandra использует JNA для блокировки JVM в память с помощью mlockall, чтобы избежать замены JVM. Я думаю, что производительность будет очень плохой, если ОС решит поменять JVM на диск ...

Я знаю, что в более ранних версиях Cassandra JNA также использовалась для создания жестких ссылок, но так как это поддерживается на Java> = 7, я думаю, что последние версии Cassandra используют Java API для создания жестких ссылок вместо JNA.