Реестр дерекқорына арналған сервер: кешігулер мен сенімділік

Неліктен тіркеу жүйелері қуатты серверде де бәсеңдеуі мүмкін

Тіркеу базалары әдетте OLTP режимінде жұмыс істейді: көп қысқа операциялар, олардың тез әрі болжамды аяқталуы керек. Сондықтан «топ» сервер де сұраулар баяулауы мүмкін, егер «шағын» әр қадамдағы кешігулер — әлсіз буын болса.

Типтік көрініс: орташа жауап уақыты қалыпты көрінеді, бірақ сирек шыңы пайда болады. Пайдаланушы картаны 200–300 мс ішінде ашады, ал кенет 3–5 секундқа дейін кідіріс байқалады. Көбіне бұл CPU жүктемесінде емес, күту уақытында: диск оқу, журналға жазу, блокировкалар, жад үшін бәсекелестік.

Кешігулер мен «тар орындардың» белгісі (есептеу қуаты жетпей тұрған жоқ екенін көрсететін):

• тез сұраулар кейде секундтар бойы «жабысып» қалады;
• транзакциялар төмен жүктеуде де ұзақ коммит жасайды;
• I/O және блокировкалар кезегі өседі;
• жауап уақыты күн бойы себепсіз «қалқып» жүреді.

Тіркеуді есептеу және аналитикадан ажырату маңызды. Аналитикада кең скандар мен параллелизм қажет, сондықтан қосымша ядра жиі көмектеседі. Тіркеу жылдам жеке оқуларға, журналдың тұрақты жазылуына және бәсекелестік кезінде минимум үзілістерге тәуелді.

Надежность (сенімділік) жылдамдықтан кем емес маңызды. Бір қуат сөнуі, жад қатесі немесе диск істен шығуы қайтаруды, ұзақ қалпына келтірілдіруді және тоқтауларды (простой) әкелуі мүмкін — бұл миллисекундтардан гөрі анағұрлым зиянды.

Қай кешігулерді нақты өлшейсіз: бастаудан бұрын

Сервер таңдамас бұрын «баяу» дегенде нені айтатыныңызды келісіңіз. Тіркеулерде көбіне есептеу қуаты емес, тарда болған кешігулер зиян келтіреді: CPU, жад, диск, сеть, транзакция арасындағы блокировкалар және журнал жазу.

Пайдаланушы тәжірибесін көрсететін метрикаларды алыңыз. Орташа жауап көбіне алдайды: ол «нормалды» болуы мүмкін, бірақ минут сайын сұраулар бір секундқа тұрып қалуы мүмкін. Сондықтан p95 және p99 перцентильдері маңызды. Егер p99 жоғары болса — жүйе тұрақсыз сезіледі.

Кешігу қабат бойынша бөлінсін:

• операциялар бойынша p95 и p99 (оқу, жазу, іздеу, жаңарту);
• диск латенттігі (жазбаға ерекше мән беріңіз), IOPS және queue depth;
• блокировкалар және commit уақыты;
• CPU жүктемесі және iowait үлесі;
• қосымша мен СУБД арасындағы желілік кешігулер.

Қысқа мысал: тіркеуде көп кішкентай транзакция бар және коммиттер жиі жасалады. Орташа сұрау уақыты 30 мс, бірақ p99 пиковте 800 мс-ке дейін секіреді. Себеп жиі ядрода емес, журналдың баяу томға жазылуынан немесе диск кезегінде тұруынан болады.

Дамыту және эксплуатация командаларынан сұраңыз: транзакцияның орташа көлемі қанша, коммиттер қаншалықты жиі, пиков уақыттар қашан, қандай операциялар критикалық және бизнеске қандай p95/p99 қажет. Бұл жауаптар тесттер мен метрикаларды анықтауға көмектеседі.

CPU және NUMA: қашан «көп ядро» көмектемейді

Көп тіркеу сұраулары есептелетін ядродағы қысқа операцияларға сүйенеді. Мұндай жүктемелерде жоғары жиілік пен IPC (ядроның циклдағы пайдалы жұмысы) маңыздырақ, неғұрлым көп ағындар емес. Бұл әсіресе көп қысқа сұраулар, блокировкалар, индекстер және белсенді транзакция журналы бар кезде көрінеді.

NUMA қосымша тәуекел тудырады. Екі сокеттік жүйелерде (кейде бір сокеттегі платформаларда да) жад түйіндерге бөлінеді. СУБД үдерісі бір түйінде жүрсе, ал деректер басқа түйінде орналасса, жадқа қатынау межпроцессорлық шинаны пайдаланып, кешігу болжамсыз болады. Графиктерде бұл сирек, бірақ ауыр p99 шыңдары ретінде көрінеді.

Энергия үнемдеу режимдері де тұрақтылықты бұзуы мүмкін. Турбо режимдер мен терең C-state күйлері үнемдеуге пайдалы, бірақ жиіліктің «қалқып» жүруіне және ояну кезінде микропаузаға әкелуі мүмкін. Тіркеулерге арналған серверлерде жиі CPU жұмысының болжамды режимін бекіту дұрысырақ.

Ресурстарды рөлдерге бөлуді ойлаңыз:

• негізгі СУБД ағындарына ядролар және фондық тапсырмаларға бөлек резерв (vacuum, бэкапы, репликация);
• СУБД ағындары жұмыс істейтін сол NUMA-түйіндерге жадты байлау;
• журнал және диск қызметі үшін бөлек ресурстар, олар CPU уақытын «жеп» жібермеу үшін.

Жад: көлемі, ECC және жылдамдық — тұрақты жауаптың негізі

RAM көлемі кешігулерді орташа емес, ең нашар сәттерде қысады. Жұмыс деректері мен индекстер СУБД кэші мен ОС кэшінде тұрса, сұраулар көбіне жадыдан өңделеді. RAM жетпесе, диск оқулары басталады, ал тез NVMe де p95/p99 кешігулерінің өсуіне әкеледі, әсіресе параллельді сұрауларда.

ECC жад — тіркеулер үшін маңызды. «Дымқыл» бит қателері сирек болса да, салдары ауыр: беттің бұзылуы, сұрау нәтижесінің дұрыстығы бұзылуы немесе процестің құлауы. ECC бэкап пен репликацияны алмастырмайды, бірақ мұндай тосынсыйлардың ықтималдығын төмендетеді.

Жад жылдамдығы мен каналдар саны да пиктердегі кешігулерге әсер етеді. Модульдерді дұрыс орналастырмаған кезде каналдар толық пайдаланылмай, өткізу қабілеті төмендейді. Сондықтан платформаға сәйкес модуль конфигурациясын алдын ала таңдап алу керек.

Қарапайым бағалау әдісі:

• жұмыс жиынтығын бағалаңыз: ең жиі қолданылатын кестелер мен индекстер;
• СУБД буферлері мен ОС қажеттіліктерін қосыңыз (соның ішінде қосылымдар мен фондық тапсырмалар);
• 12–24 айға өсуге запас қалтырыңыз және пиковқа резерв қойыңыз;
• слоттар мен жиіліктің шектеулерін болжайтын болыңыз.

Диск пен сақтау: медленный сұраулардың негізгі себебі

Тіркеулерде тежелу көбіне CPU-да емес, сақтауда басталады. Сұрау қарапайым болса да, диск күтуіне тірелсе, серверде көп ядро бар болса да ұзақ паузалар болады.

Айырмашылық ең алдымен латенттілікте байқалады. SATA SSD HDD-дан жылдамырақ болуы мүмкін, бірақ жауап уақыты мен параллелді жұмыста NVMe жиі үздік болады. Сонымен қатар құрылғының класы маңызды: тұтынушылық SSD ұзақ жазу кезінде кенет нашарлап қалуы мүмкін, ал серверлік модельдер тұрақты жауап пен болжамды кешігулерді ұстайды.

Жиі қолданылатын тәжірибе: журналды және деректерді бөлу. Журнал (WAL/redo) тұрақты синхронды жазуды талап етеді — оған минималды кешігулер керек. Деректер мен индекстер басқа талаппен жұмыс істейді.

Кәдімгі схема:

• транзакция журналын бөлек жылдам NVMe-ға қою;
• деректер мен индекстерді басқа пулға орналастыру;
• уақытша файлдар мен сұрыптауларды бөлек орналастыру.

RAID және контроллер де кешігулерге әсер етеді. Жазба кэшінің және қуатты қорғаудың (батарея немесе суперконденсатор) болуы write-back режимінде жазу кешігулерін айтарлықтай төмендетуі мүмкін. Бірақ қуатты қорғаусыз write-back қауіпті — сөну кезінде растаған операцияларды жоғалту және консистенттік мәселелері мүмкін.

DWPD/TBW және PLP сияқты көрсеткіштерге назар аударыңыз. Көп кішкентай жазбалар және жиі коммиттер болатынын ескеріп, төмен ресурсқа ие SSD тез «шаршап», троттлингке түсіп, кешігулер өседі.

Сенімділік: не істей береді, не істей алмайды аппарат

Тіркеулер үшін жылдамдық пен болжамдылық маңызды. Тіпті жақсы сервер бөлек компоненттің істен шығуынан сағаттап тоқтап қалса, ол пайдалы емес.

Нені істен шыққанда жұмысын жалғастыруы керек екенін айқындаңыз: жүктеу дискісі мен СУБД журналдары, негізгі деректер сақтау, қуат және бір қолданбалы түйін болуы жиі міндетті саналады.

Практикалық базалық схема:

• жүйелік том мен журналдар үшін RAID1 және жылдам қалпына келтірілу;
• деректерге бөлек массив, жауап уақыты тұрақты болуын басым ету;
• резервтік түйін (hot standby) егер қысқа тоқтау қабылданбаса;
• екі қуат блогы және тұрақты электропитание схемасы.

RAID дискіні қорғайды, бірақ әкімші қатесі, логикалық бұзылыс немесе зиянды бағдарламадан сақтамайды. Сондықтан сенімді бэкап пен оның қалпына келу мүмкіндігі маңызды.

Репликация және кластер: тоқтауды емес, кешігулерді шешпейді

Репликация мен кластерлер әдетте простайды азайтады: басқа көшірмеге ауысып қызмет қалпына келеді. Бірақ олар кешігулер проблемасын түпкілікті шешпейді: егер журнал немесе индекстер себеп болса, реплика да баяу болады.

Бизнеспен RPO (қандай деректерді жоғалтуға болады) және RTO (қалайша тез қалпына келу керек) көрсеткіштерін келісіңіз. Мысалы, 5 минут RPO және 30 минут RTO — бұл таңдау мен архитектураға әсер етеді.

Қазақстанда серверлер мен сервисті сатып алғанда компоненттердің ауыстырылуына және сервис инженері келу мерзіміне назар аударыңыз — бұл сіздің нақты RTO-ға әсер етеді.

Желі: кешігулер «қалқымасын» үшін

Қуатты серверде де желі жауаптың болжамсыз болуына себеп болуы мүмкін. Мәселе тек өткізу қабілетінде емес: коммутаторлар кезектері, порт қателері немесе трафиктің әртүрлі жолдармен өтуі (бір сұраудың бөлігі бір коммутатордан, бөлігі басқа) кешігулерді тудырады.

Трафикті бөліп қою жиі көмектеседі: клиенттік сұраулар, репликация және бэкап бір арнада жүрмесін. Түнгі бэкап күндізгі жұмысты бұзуы мүмкін.

Проверка үшін минимум:

• клиент сұраулары үшін бөлек желі/VLAN;
• репликация және ішкі трафик үшін бөлек желі;
• резервтік көшіру үшін бөлек желі;
• кластер түйіндерінің бәрі үшін бірдей маршрут пен линк жылдамдығы;
• порттардағы қателер мен падение статистикасын бақылау.

Қашан 10/25/40/100GbE ойлану керек? Егер база белсенді түрде жазады/оқыса (репликация, бэкаптар), гигабит кейде пиковте тьюингтік шектеу бола алады: кезек қысқа уақытта өсіп, кешігулер «плавают» болады.

СУБД және жұмыс схемасы: аппарат баптамасын алмастырмайды

Қымбат сервер де сұраулар бір-біріне кедергі келтірсе көмектеспейді. Көп кешігулердің себебі — блокировкалар және бірдей жазбаларды әр түрлі тәртіпте жаңарту. Бұл көбіне қолданба ұзақ ашық транзакциялар жүргізгенде немесе шынымен бір уақытта көп жазулар болғанда болады.

Индекстер мен статистика аппараттан гөрі жиі үлкен әсер береді. Қате жоспарланған сұрау үлкен кестені скандеуі мүмкін. Транзакция өлшемі мен коммит жиілігі журналға тікелей әсер етеді: тым жиі коммиттеу журналға қысқа жазбалар жібереді, тым үлкен транзакция блокировкаларды және қалпына келтіру уақытын ұлғайтады.

Қосылымдар қатері — әр сұрау жаңа қосылым ашатын немесе пул лимиттерсіз конфигурацияланған кезде сервер көп сессия алып, контекст ауысуға уақыт жұмсайды.

Проверка үшін минимум:

• ең ауыр сұрауларды табу (уақыт және сан бойынша);
• индекстер мен статистиканың дұрыстығын тексеру;
• транзакция ұзақтығын және блокировкалардағы күту үлесін өлшеу;
• қосылым пулын реттеу және параллелизмге шектеу қою;
• қандай операциялар фонға шығарылып пакетте орындалатынын анықтау.

Қадамдар бойынша конфигурация таңдау

Қате жиі CPU моделінде емес, «орташа қуатты сатып алып» қай жерде нақты кешігулер туындайтынын білмеуде болады. Оңтайлы жоспар: өлшеуден бастап конфигурацияға дейін, содан кейін тексеру.

Алдымен тіркеудің күнделікті операцияларын анықтаңыз: кілт бойынша іздеу, жаппай жаңартулар, пакет жүктеу, шығару формалау, түнгі сверка. Әрбір операция үшін шекті жауап уақытын және параллель пайдалану санын белгілеңіз.

Орташа мәндерге қарамаңыз — p95 және p99-ды ашыңыз және бұл көрсеткіштерді жүктеменің қай сәттерімен салыстырыңыз: CPU, жад қысымы, диск кезегі, желілік үзілістер.

Практикалық тәртіп:

• жүктеме профилін алыңыз;
• ағымдағы p95/p99 және тар орындардың белгілерін анықтаңыз;
• тар орынға бағытталған конфигурация жасаңыз: ECC жад, NVMe журналға, анық RAID, желінің резервтелуі;
• рөлдерді ажыратыңыз: журнал бөлек, бэкап басқа құрылғыда, репликация мен мониторингты бастап қойыңыз;
• нагрузочное тестирование өткізіп, мақсатты метрикаларды бекітіңіз.

Жиі жіберілетін қателер

Ең кең таралғаны — серверді «ядро мен гигабайттар бойынша» сатып алу, нақты кешігулер қайдан пайда болатынынсыз. Көп жағдайда кешігулер диск, журнал және қуатты үнемдеу баптауларынан туады, не CPU-негізінде емес.

Типтік сценарий: қуатты CPU, үлкен RAID HDD немесе «универсал» SSD, бірақ журнал бір массивте. Нәтижесінде журнал кіші блоктармен жазылып, фондық тапсырмалармен бәсекеге түседі және пиковые кешігулер пайда болады.

Басқа жиі қателер:

• деректер мен журнал бір жерде, фондық операциялар сұрауларды «ежеу»;
• құрылғыларды орташа жылдамдыққа қарап таңдау, p99 көрсеткішін ескермей;
• энергосбережение әдепкіде қалдырылған: CPU терең C-state-ке өтіп, жиілік «қалқып» жүреді;
• ОС немесе гипервизордың планировщик баптауларын тексермеу, I/O кезегін тудыруы мүмкін;
• бэкапты тек жазып қою, бірақ қалпына келтіру тестін өткізбеу.

Тез чек‑лист сатып алудан бұрын

Сатып алмас бұрын мақсаттарды анықтаңыз: қандай p95/p99, рұқсат етілген простой, RPO және RTO. Бұл дұрыс конфигурацияны таңдауға көмектеседі.

Техникалық тексеру:

• CPU: сіздің сұраулардағы өнімділік; жиілік көбіне маңызды; NUMA-ны ескеріңіз;
• Жад: жеткілікті көлем, тек ECC, модульдер каналдарға сәйкес орнатылғанын тексеріңіз;
• Диски: NVMe журналға, жазу ресурсы (TBW/DWPD) және қуатты қорғау бар-жоғын қараңыз;
• Надежность: қайталама дискілер, БП және детальдық процедура бэкап пен қалпына келтіру үшін;
• Инфрақұрылым: репликацияға арналған желі, мониторинг және журналдау.

Практикалық тест: сіздің ауыр сұрауды типтік жүктеме астында орындап көріңіз. Егер p99 «тұра бастаса», әдетте кінә сақтау немесе NUMA.

Практикалық мысал

Кейс: мемлекеттік реестр, таңертеңгі және ай соңындағы пиковтар. Қағазда бәрі дұрыс: көп ядра, жеткілікті жад, бірақ пайдаланушылар кейде «тұрып қалуды» сезінеді. Әдетте p99 дискте — журнал бір томда орналасқан және деректермен бәсекеге түседі.

Шешім: журналды жылдам NVMe-ға шығарып, деректерді басқа томда қалдырды. Уақытша файлдар мен бэкаптарды бөлек шығарды. Серверде энергопрофильді өнімділікке қойып, NUMA-привязканы реттеді.

Нәтиже: орташа жауап уақыт шамалы өзгерді, бірақ p95 және p99 көрнекті жақсарды — таңертеңгі пиктер тыныш өтіп кетті. Сонымен бірге нақты қалпына келтіру жоспары пайда болды.

Келесі қадамдар: таңдауынан жұмыс істейтін жүйеге дейін

Талаптарды тексерілетін формада бастаңыз: типтік операциялар үшін мақсатты p95/p99 және RPO/RTO көрсеткіштерін бекітіңіз. Архитектураны келісімдеңіз: кейде жалғыз сервер жақсырақ, кейде резерв пен репликация қажет.

Перед закупкой проверьте пилот на ваших данных:

• нагрузочное тестирование, p95/p99 фиксациясы;
• қалпына келтіру тесті: диск істен шығу, переключение на резерв;
• бэкап пен қалпына келтіру уақыты бағасы;
• мониторинг CPU, жад, I/O, желі және СУБД латенттілігін көру;
• нәтижелерді және конфигурацияны құжаттау.

Егер локальды жеткізу және сервис қажет болса, Қазақстанда GSE S200 Series негізінде интегратормен жұмыс істеу ыңғайлы болуы мүмкін.

Финалдық қадам — эксплуатация регламенты: жаңарту терезелері, қолжетімділік ережелері, бэкап кестесі, қалпына келтіру тесттері, алертке реакция және анық RTO/RPO. Бұл конфигурацияны тұрақты жұмыс істейтін жүйеге айналдырады.