Próby przekroczenia progu ostrzegania i awaryjnego Cassandra Tombstoning

Prowadzimy serwer Titan Graph DB wspierany przez Cassandrę jako magazyn trwały i napotykamy problem z osiągnięciem limitu progów nagrobków Cassandra, który powoduje okresowe zawieszenie naszych zapytań/limitu czasu gromadzą się dane. Wygląda na to, że zagęszczanie nie jest w stanie nadążyć za liczbą dodanych nagrobków.Próby przekroczenia progu ostrzegania i awaryjnego Cassandra Tombstoning

Nasz przypadek użycia obsługuje: przepustowość

Wysoka odczytu/zapisu.
Wysoka wrażliwość na odczyty.
Częste aktualizacje wartości węzłów w programie Titan. powodując aktualizację wierszy w Cassandrze.

Biorąc pod uwagę powyższe przypadki użycia, jesteśmy już optymalizację Cassandrę agresywnie wykonaj następujące czynności:

Agresywny ubicie za pomocą wyrównał strategie zagęszczania
Korzystanie tombstone_compaction_interval jak 60 sekund.
Stosując tombstone_threshold do 0,01
Ustawienie gc_grace_seconds się 1800

Pomimo następujących optymalizacji, wciąż widzenia ostrzeżenia w Cassandry rejestruje podobne do: [OSTRZEGAJ] (ReadStage: 7510) org .apache.cassandra.db.filter.SliceQueryFilter: Odczytuje 0 żywych i 10350 zniszczonych komórek w .graphindex (patrz tombstone_warn_threshold). 8001 Kolumny zażądano, kromki = [00-FF], delInfo = {deletedAt = -9223372036854775808, localDeletion = 2147483647}

Czasami wraz z upływem czasu, widzimy także próg awarii naruszone i powoduje błędy.

Nasz plik cassandra.yaml ma wartość tombstone_warn_threshold równą 10000, a tombstone_failure_threshold jest znacznie wyższa niż zalecana przy 250000, bez żadnych zauważalnych korzyści.

Każda pomoc, która może wskazać nam właściwą konfigurację, byłaby bardzo doceniana, jeśli istnieje możliwość dalszej optymalizacji. Z góry dziękuję za poświęcony czas i pomoc.

Źródło

2015-03-10 Rohit

Czy często usuwasz dane? Rozumiem, że nagrobki nie są tworzone, chyba że dane zostaną jawnie usunięte lub wygasną. –

Jesteśmy przekonani, że Titan GraphDb, który obsługuje wszystkie nasze interakcje z Cassandrą wewnętrznie, może wykonywać usuwanie i tworzyć nowe dla każdej aktualizacji, co zwiększa liczbę usunięć. – Rohit

Byłoby dobrze, gdyby tak było. Czy możesz włączyć śledzenie probabilistyczne (http://www.datastax.com/documentation/cassandra/2.0/cassandra/tools/toolsSetTraceProbability.html) na jednym z twoich węzłów Kasandra, aby zobaczyć, jakie są te usunięcia? Inną możliwością jest to, że kolumny są wygasłe (zestaw z TTL), myślisz, że to może się dziać tutaj również? –

Nagrobki nie są zagęszczane, dopóki nie upłynie konfiguracja gc_grace_seconds na stole dla danego nagrobka. Więc nawet zwiększając czas zagęszczania twoje nagrobki nie zostaną usunięte, dopóki nie upłynie czas gc_grace_seconds, przy czym domyślnie będzie to 10 dni. Możesz spróbować dostroić gc_grace_seconds do niższej wartości i robić naprawy częściej (zazwyczaj chcesz zaplanować naprawy, aby zdarzyły się co gc_grace_seconds_in_days - 1 dzień).

Źródło

2015-03-10 19:54:46

Dzięki za odzyskanie Andy. Dobry punkt, o którym wspomniałeś. Ustawiamy również sekundy łaski Gc na 1800. Poprawiłem swój post, aby odzwierciedlić tę próbę również z naszej strony. – Rohit

Wygląda na to, że źródłem problemu jest twój model danych. Zrobiłeś wszystko, co możesz, aby złagodzić efekt TombstoneOverwhelmingException. Ponieważ twój model danych wymaga tak częstych aktualizacji, które powodują powstanie nagrobka, ostateczny, spójny magazyn, taki jak Cassandra, może nie pasować do twojego przypadku użycia. Kiedy doświadczyliśmy tego typu problemów, musieliśmy zmienić nasz model danych, aby lepiej pasował do mocnych stron Cassandry.

O usuwa http://www.slideshare.net/planetcassandra/8-axel-liljencrantz-23204252 (slajdy 34-39)

Źródło

2015-03-10 20:37:42

Dzięki Curtis. Przyjrzę się temu i zobaczę, czy są jakieś zmiany, które możemy wprowadzić za pomocą modelu danych. Częściowo problem polega na tym, że za pomocą serwera graficznego Titan model danych jest od nas wydzielany. – Rohit

Witam @Rohit Możesz się zorientować, w jaki sposób Titan utrzymuje dane z [tutaj] (http://s3.thinkaurelius.com/docs/titan/0.5.4/data-model.html). Zasadniczo musieliśmy zminimalizować usunięte wierzchołki i krawędzie. –

zmienne, które zostały dostrojone są pomagając wygasają nagrobków, ale warto zauważyć, że podczas gdy nagrobki nie może być czyszczona aż gc_grace_seconds Cassandra nie udziela żadnych gwarancji, że nagrobki WOLĘ być wyczyszczone w gc_grace_seconds. Rzeczywiście, nagrobki nie są zagęszczane, dopóki nie zostanie zagęszczone sstable zawierające nagrobek, a nawet wtedy, nie zostanie ono wyeliminowane, jeśli jest inna warstwa zawierająca celę, która jest zacieniona.

Powoduje to, że nagrobki mogą trwać bardzo długo, szczególnie jeśli używasz sstables, które są rzadko zagęszczane (np. Bardzo duże pliki STCS). Aby rozwiązać ten problem, istnieją narzędzia, takie jak punkt końcowy JMX, który wymusza metodę forceUserDefinedCompaction - jeśli nie jesteś biegły w korzystaniu z punktów końcowych JMX, narzędzia do wykonywania tej czynności automatycznie istnieją, takie jak http://www.encql.com/purge-cassandra-tombstones/

Źródło

2015-04-25 20:57:36

Wszyscy tutaj mają rację. Jeśli często naprawiasz i kompaktujesz, zmniejsz swój numer gc_grace_seconds.

Warto jednak pamiętać, że wstawianie wartości Null jest równoznaczne z usunięciem. Pozwoli to zwiększyć liczbę nagrobków. Zamiast tego musisz wstawić UNSET_VALUE, jeśli używasz przygotowanych instrukcji. Prawdopodobnie dla ciebie za późno, ale jeśli ktoś tu przyjdzie.

Źródło

2017-04-18 18:56:32 Highstead

Próby przekroczenia progu ostrzegania i awaryjnego Cassandra Tombstoning

Odpowiedz

Powiązane problemy