Vlákno názorů k článku Jak nikdy nespouštět službu, aneb kdo posílá tajemný SIGKILL? od Ladislav Michl - "Pokud není množství chyb v poměru k celkovému...
-
Ladislav Michl (neregistrovaný)
"Pokud není množství chyb v poměru k celkovému počtu událostí statisticky významné, není třeba nic řešit."
Moc pěkný přístup... Po přečtení "Byl to zkrátka takový ošklivý… nepěkná věc," mě napadá jiný citát stejného autora: "To muselo dát práce a přitom je to taková blbost!" Aneb two-liner v kernel/signal.c by byl efektivnější. Teda v normálním prostředí, protože pokud je enterprise tak rock solid, že běží na CentOS 6, je asi nemožné mít pro pokusy vlastní jádro.
-
> "Pokud není množství chyb v poměru k celkovému počtu událostí statisticky významné, není třeba nic řešit."
Tak ono pokud procesujes miliardy zaznamu denne, tak ti proste urcite chyby vznikaji. Neco se obcas nekde nedokomunikuje, posle dvakrat, ...
A je to fuk, pokud se o tom vi a bud se pak tyto chyby eliminuji, nebo jsou pro dalsi zpracovani dat nepodstatne.Navrh velkych BigData systmeu je dost casto o spouste kompromisu, takze autora v tomhle docela chapu. Ale jak jsem clanek cetl, tak jsem si rikal, ze se toho urcite nekdo chyti :)
A co bys resil tou upravou v jadre (pomineme fakt, ze upravovat jadro je fakt spatny napad).
-
Ladislav Michl (neregistrovaný)
Úprava není řešení, jen pomůcka, která mi řekne, kdo poslal SIGKILL. To, co je v článku popsané muselo být dosti zdlouhavé.
Ačkoliv, ale nikde to neříkejte, by bylo snadné naprasit, aby se SIGKILL od určitého procesu neposílal - a kdyby použíté jádro umělo runtime patching... Oprava příčiny je samozřejmě v pořádku, praso řešení by se nabízelo, kdyby mi za zády podupkával nadřízený a chtěl to "hned nějak opravit"."Ale to je fuk..." - asi ano, nedokážu to posoudit. K problému se dostanu až si všimne manažer, do té doby je to problém někoho jiného ;-)
