Позволете ми да обсъдя тема, която по своята същност не е специфична за PostgreSQL, но с която редовно се сблъсквам, докато проучвам проблеми на клиентските системи, оценявам „поддържаемостта“ на тези системи и т.н. Важно е да имате решение за мониторинг на системните показатели, да го конфигурирате разумно , и защо sar все още е любимият ми инструмент (поне в Linux).
Относно важността на наблюдението
Първо, наблюдението на основните системни показатели (CPU, I/O, памет) е изключително важно. Малко странно е да се налага да се посочи това в дискусии с други инженери, но бих казал, че 1 от 10 инженери смята, че всъщност не се нуждаят от наблюдение. Разсъжденията обикновено вървят в следните линии:
Наистина наблюдението добавя допълнителни разходи, без съмнение. Но вероятно е незначително в сравнение с това, което прави приложението. Всъщност, sar всъщност не добавя никакви допълнителни инструменти, а просто чете броячи от nernel, изчислява делта и записва това на диск. Може да се нуждае от малко дисково пространство и I/O (в зависимост от броя на процесорите и дисковете), но това е всичко.
Например събирането на статистически данни за секунда на машина с 32 ядра и множество дискове ще произвежда ~5GB сурови данни на ден, но се компресира изключително добре, често до ~5-10%). И почти не се вижда в top . Разделителната способност за секунда е малко екстремна и използването на 5 или 10 секунди допълнително ще намали допълнителните разходи.
Така че не, оказва се, че режийните разходи всъщност не са основателна причина да не се активира наблюдението.
Разходи срещу ползи
По-важното обаче е:„Колко режийни разходи да премахна, като не активирам наблюдението?“ е грешен въпрос за задаване. Вместо това трябва да попитате „Какви ползи получавам от наблюдението? Ползите надвишават ли разходите?”
Вече знаем, че разходите (режийните) са сравнително малки или напълно незначителни. Какви са ползите? Според моя опит разполагането с данни от мониторинг е ефективно безценно.
Първо, той ви позволява да проучвате проблеми – разглеждането на куп диаграми и търсенето на внезапни промени е изненадващо ефективно и често ви отвежда директно до правилния проблем. По същия начин, сравняването на текущите данни (събрани по време на издаването) с базови (събрани, когато всичко е наред) е много полезно и невъзможно, ако активирате наблюдението само когато нещата се повредят.
Второ, тя ви позволява да оценявате тенденциите и да идентифицирате потенциални проблеми, преди те действително да ви ударят. Колко CPU използвате? Използването на процесора нараства ли с времето? Има ли някакви подозрителни модели в използването на паметта? Можете да отговорите на тези въпроси само ако имате мониторинг.
Защо sar е любимият ми инструмент
Да предположим, че съм ви убедил, че наблюдението е важно и определено трябва да го направите. Но защо е sar любимият ни инструмент, когато има различни фантастични алтернативи, както локални, така и базирани в облак?
- Включен е във всички дистрибуции и е тривиален за инсталиране/настройка. Това прави доста лесно да се убедят хората да го активират.
- Това е точно на машината. Така че, ако използвате SSH към машината, можете да получите и данните за наблюдение.
- Използва прост извеждане на текст. Тривиална обработка на данните – импортирайте ги в база данни, анализирайте, прикачете ги към билет за поддръжка. Това е доста трудно с други инструменти, които обикновено не ви позволяват лесно да експортирате данните, показват само диаграми и/или значително ограничават какъв анализ можете да извършвате и т.н.
Признавам, че част от това идва от факта, че работя за компания, предоставяща PostgreSQL услуги на други компании (било то 24×7 поддръжка или отдалечен DBA. Така че обикновено получаваме само много ограничен достъп до клиентски системи (най-вече само сървъри на бази данни и нищо повече). Това означава, че разполагането с всички важни данни на самия сървър на база данни, достъпни през обикновен SSH, е изключително удобно и елиминира ненужните двупосочни пътувания само за заявка на друга част от данни от друга система. Което спестява време и разум от двете страни.
Ако имате много системи за управление, вероятно ще предпочетете решение за наблюдение, което събира данни от много машини на едно място. Но за мен sar все още печели.
И така, как да го конфигурирам?
Споменах инсталиране и активиране на sar (или по-скоро sysstat , което е пакетът, включващ sar ) е много проста. За съжаление конфигурацията по подразбиране е малко лоша. След инсталиране на sysstat , ще намерите нещо подобно в /etc/cron.d/sysstat (или където и където вашата дистрибуция съхранява cron конфигурация):
*/10 * * * * root /usr/lib64/sa/sa1 1 1
Това ефективно казва sa1 командата ще се изпълнява на всеки 10 минути и ще събира единична проба за 1 секунда. Тук има два проблема. Първо, 10 минути са сравнително ниска разделителна способност. Второ, извадката обхваща само 1 секунда от 600, така че останалите 9:59 всъщност не са включени в нея. Това е донякъде добре за дългосрочни тенденции, където произволната извадка с ниска разделителна способност е достатъчна. За други цели вероятно трябва да направите нещо подобно:
* * * * * root /usr/lib64/sa/sa1 -S XALL 60 1
Което събира една проба на минута и всяка проба обхваща една минута. -S XALL означава, че всички статистически данни трябва да бъдат събрани, включително прекъсвания, отделни блокови устройства и дялове и т.н. Вижте man sadc за повече подробности.
Резюме
И така, да обобщим тази публикация в няколко прости точки:
- Трябва да имате наблюдение, дори ако смятате, че нямате нужда от него. След като срещнете проблеми, вече е твърде късно.
- Разходите за наблюдение вероятно са незначителни, но със сигурност много по-ниски от ползите от наличието на данните от мониторинга.
sarе удобно и много ефективно. Може би ще използвате нещо друго в бъдеще, но това е добра първа стъпка.- Конфигурацията по подразбиране не е особено добра (ниска разделителна способност, 1-секундни проби). Помислете за увеличаване на разделителната способност.
Едно нещо, което не споменах, е това sar се занимава само със системни показатели – процесор, дискове, памет, процеси, а не със статистика на PostgreSQL. Определено трябва да наблюдавате и тази част от стека, разбира се.
