Jeg har en tabel, og der er kun \u00e9n partition i tabellen, den er ReplacingMergeTree. Jeg har skrevet data i den i fire \u00e5r. Jeg skulle lave en alterering i den og slette nogle data.<\/p>\n
Jeg gjorde det, og under behandlingen af denne foresp\u00f8rgsel blev al hukommelse brugt p\u00e5 alle servere i klyngen, og alle servere i klyngen gik i OOM. Derefter kom de alle sammen op igen, begyndte at udf\u00f8re mergeren af netop denne operation, denne datablok, og faldt igen i OOM. S\u00e5 rejste de sig op igen og faldt igen. Og denne ting stoppede ikke.<\/p>\n
Sen viste, at dette faktisk var en fejl, som folkene har rettet. Det er rigtig godt, mange tak. Men der er stadig en rest. Og nu, n\u00e5r jeg t\u00e6nker p\u00e5, hvad jeg skal g\u00f8re med et merge i tabellen, dukker sp\u00f8rgsm\u00e5let op \u2014 hvorfor kan jeg ikke p\u00e5 en eller anden m\u00e5de p\u00e5virke disse merges? For eksempel begr\u00e6nse dem i forhold til den n\u00f8dvendige m\u00e6ngde RAM, eller generelt i forhold til antallet af dem, der skal behandle denne specifikke tabel.<\/p>\n
Jeg har en tabel, der hedder \"Metrier\", venligst behandl den i to tr\u00e5de for mig. Lad v\u00e6re med at skabe ti eller fem merges parallelt, lav det i to. Jeg tror, at to vil v\u00e6re tilstr\u00e6kkeligt med hukommelse, men til at behandle ti m\u00e5ske ikke. Hvorfor forts\u00e6tter frygten? Fordi tabellen vokser, og en dag vil jeg st\u00e5 over for en situation, hvor det ikke l\u00e6ngere skyldes en fejl, men fordi dataene vil \u00e6ndre sig i s\u00e5 stort omfang, at jeg simpelthen ikke vil have tilstr\u00e6kkelig hukommelse p\u00e5 serveren. Og s\u00e5 vil serveren falde i OOM ved merge. Desuden kan jeg annullere mutationer, men merges kan jeg ikke.<\/p><\/blockquote>\n
Du ved, ved merges vil serveren ikke falde i OOM, fordi der ved merge kun anvendes m\u00e6ngden af hukommelse til et lille datainterval. S\u00e5 alt vil v\u00e6re fint uanset datam\u00e6ngden.<\/p>\n
<\/p>\n
Vladimir Kolobaev:<\/strong> Det er fint. Der er den detalje, at efter at fejlen blev rettet, downloadede jeg den nye version og udf\u00f8rte en lignende operation p\u00e5 en anden tabel, der var mindre og havde mange partitioner. I l\u00f8bet af merges blev der brugt omkring 100 GB RAM p\u00e5 serveren. Jeg havde 150 GB optaget, 100 GB blev brugt, og der var et vindue p\u00e5 50 GB, s\u00e5 jeg faldt ikke i OOM.<\/p>\n<\/p>\n
Hvad beskytter mig i \u00f8jeblikket mod at falde i OOM, hvis det virkelig forbruger 100 GB RAM? Hvordan skal jeg h\u00e5ndtere en situation, hvor RAM pludselig l\u00f8ber t\u00f8r under merges?<\/p>\n
<\/p>\n
Alexey Milovidov:<\/strong> Der er et problem med, at forbruget af RAM under merging ikke er begr\u00e6nset. Det andet problem er, at hvis en merging er planlagt, skal den udf\u00f8res, fordi den er skrevet i replikationsloggen. Replikationsloggen indeholder de handlinger, der er n\u00f8dvendige for at bringe replikatet i en konsistent tilstand. Hvis man ikke udf\u00f8rer de manuelle handlinger, som denne replikationslog vil tilbagef\u00f8re, m\u00e5 man p\u00e5 den ene eller anden m\u00e5de gennemf\u00f8re merging.<\/p>\n<\/p>\n
Selvf\u00f8lgelig ville det ikke v\u00e6re d\u00e5rligt at have en begr\u00e6nsning p\u00e5 RAM, der \"for en sikkerheds skyld\" beskytter mod OOM. Det vil ikke hj\u00e6lpe merging til at blive udf\u00f8rt, den vil begynde igen, n\u00e5 en t\u00e6rskel, kaste en undtagelse og s\u00e5 starte forfra \u2013 der kommer ikke noget godt ud af det. Men generelt ville det v\u00e6re nyttigt at indf\u00f8re en s\u00e5dan begr\u00e6nsning.<\/p>\n
<\/p>\n
![\"ClickHouse](\"\/wp-content\/uploads\/2020\/05\/242b1d8d002fe115614435c242297fd2.jpg\")
<\/p>\n