2016-11-20 42 views
5

Próbuję zoptymalizować działanie moich kontenerów Docker Cassandra (3.7+). Znalazłem a presentation from 2015, który wspomniał (na slajdzie 21), że powinienem przyznać CAP_IPC_LOCK i ustawić blok ulimit.Cassandra, JNA, Docker i CAP_IPC_LOCK

Po drobnym wykopaniu wydaje się, że w zasadzie dwie opcje mają na celu uniemożliwienie zamiany JVM przez system, który wydaje się spełniać współczesne wersje Cassandry przy użyciu JNA.

Ustawianie --ulimit memlock=-1:-1 na moich pojemników Döcker ma ten skutek, że

INFO 12:42:33 JNA mlockall successful 

jest drukowany podczas rozruchu, więc zakładam, że jestem cały zestaw i zrobić.

Czy nadal potrzebuję --cap-add=CAP_IPC_LOCK, a jeśli tak, jak mogę wykryć, czy ustawiłem go poprawnie?

Odpowiedz

1

Pomyślmy o tym.

w Linuksie proces potrzebuje CAP_IPC_LOCK możliwość zadzwonić mlockall.

Teraz mlockAll blokuje wszystkie wirtualne przestrzenie adresowe procesu wywoływania w pamięci RAM, uniemożliwiając stronicowanie pamięci do obszaru wymiany. Zatem zasadniczo nie pozwalam ci się zamieniać.

Instalacja JNA ma taki sam efekt.

To z Datastax docs

Instalacja JNA może poprawić pamięć Cassandra usage.When zainstalowany i skonfigurowany, Linux nie zamienić się JVM, a tym samym pozwala uniknąć podobnych problemów z wydajnością.

http://docs.datastax.com/en/cassandra/1.2/cassandra/install/installJnaDeb.html

Także jeśli widać poniżej w dziennikach

JNA mlockall successful

Oznacza to, że JNA jest włączony.

Myślę, że wszystko jest w porządku i nie trzeba dodawać CAP_IPC_LOCK.