Жадыға жоғары жүктеме болатын ERP серверлері: RAM және NUMA

Неліктен жад аз болғанда ERP баяулайды

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

Жад жетіспегенде операциялық жүйе жиі swap-қа жазады, ал дерекқор мен қосымша кэштерін жоғалтады. Кез келген операция дискіден оқу, жадыға орналастыру, кейін бір нәрсені ығыстыру тізбегіне айналады. Ядро қосу бұл мәселені шешпейді.

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

Ең жиі кездесетін қателік — мәселені қуатты CPU сатып алу арқылы шешуге тырысу. Егер себеп RAM жетіспеушілігінде болса, жаңа ядролар тезірек босқа қалады. Мониторингте бұл процессордың орта деңгейдегі жүктемесі (мысалы, 20–40%) мен жоғары дискілік белсенділік, белсенді swap және жауап уақыттарының ұлғаюы түрінде көрінеді.

Қарапайым мысал: 150 қолданушы бір уақытта ERP-да жұмыс істейді, бухгалтерия есептер құрады, ал фондықта алмасулар мен регламенттік тапсырмалар жүреді. Жад жеткілікті болғанда дерекқор «ыстық» кестелер мен индекстерді кэште ұстайды, және көп сұраныстар тез орындалады. Жад тарылғанда кэш қысқарады, дерекқор жиі дискіден оқиды, ал әр ауыр есеп күнделікті жұмыспен тікелей бәсекелеседі.

Әдетте келесі екі нәрсені жасау қажет: нақты RAM қажеттілігін бағалау және екі процессорлы жүйелердің ерекшеліктерін (NUMA) ескеру, сонда жады тиімді пайдаланылып, ядроларға артық төлемнен аулақ болуға болады.

ERP-да көбіне не жейді жадты

Сервер таңдағанда жад процессордан бұрын таусылуы жиі кездеседі. Бұл әсіресе көп бір уақытта қолданушылар мен белсенді дерекқор жағдайында тән.

Пайдаланушылар, сессиялар және фондық тапсырмалар

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

Жадты тек сессиялар ғана емес, олардың жұмыс аумақтары да (уақытша кестелер, буферлер, қосымшадағы объектілер, хабар алмасу кезектері) алады. Жеке алғанда олар кішкентай көрінсе де, пикиде айтарлықтай көлемге жинақталады.

Қосымшаның кэші және СУБД кэші

Кэш дискіні қайталап оқуды және қайта есептеуді болдырмау үшін қажет. Сондықтан RAM көбейтсе жүйе жиі CPU алмастырмай жылдамдайды.

Әдетте жадта мыналар болады:

• қосымшаның кэші (анықтамалар, құқықтар, баптаулар, жиі пайдаланылатын құжаттар)
• СУБД буферлік кэші (деректер беттері және индекстер)
• сұрыптау және JOIN-дарға арналған жұмыс жад
• уақытша деректер (temp, есептердің аралық нәтижелері)
• ОС және сервистердің шығындары (мониторинг, резервтік көшіру, антивирустық)

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

Есептер мен аналитика: қайда пики болады

Есептер, әсіресе жинақтық және «барлық бөлімдер бойынша жылдық» сияқты есептер, қысқа бірақ үлкен жарылыстар береді. Мысалы, 10:00-де бірнеше ауыр есеп бір уақытта іске қосылады, сол уақытта банкпен алмасу және саудадағы кезекті жабу жүруі мүмкін. Мұндай сәттерде жад сұрыптауларға, группалауларға, уақытша жиындарға және параллель тапсырмаларға кетеді.

Виртуализация және контейнерлер

Егер ERP мен дерекқор виртуалды машиналарда жұмыс істесе, гипервизорлық резерв пен қате лимиттер кезінде жад шығындары пайда болады, көрші ВМ-дермен бәсекелестік туады. Контейнерлер де шектеулерді талап етеді; әйтпесе бір сервис жадты «жеп» басқа қызметтерді ығыстыруы мүмкін.

Өсуге арналған запас

Ең тез өсу болатын нәрсе — ядролар саны емес, деректер көлемі мен параллель операциялар саны: көп қолданушылар, көп интеграциялар, есептерде тарихи кезеңдердің ұлғаюы. Орташа жүктемеге ғана емес, пики мен өсімге RAM запасын қою практикалықрақ.

RAM қажеттілігін қалай есептеу: қадамдық тәсіл

ERP үшін жадқа жоғары жүктеме кезінде серверді таңдау «қанша ГБ керек» деп емес, қабаттар бойынша есептемеден басталғаны жақсы: ОС пен сервистер, ERP қосымша, дерекқор және кэш пен уақытша операцияларға запас.

1‑қадам. Енгізу деректерін жинау

Шындығына сүйеніңіз, «көзге» емес:

• пиктегі бір уақытта қанша қолданушы және олар не істейді (проводкалар, есептер, ай жабу)
• дерекқор көлемі және өсім қарқыны (мысалы, тоқсан сайын +10%)
• архитектура: бір сервер ме, бөлек пе (қосымша және СУБД), виртуализация ма әлде нақты «темір» па
• пикидегі параллель тапсырмалардың саны (алмасулар, регламенттер, интеграциялар)
• ағымдағы метрикалар: RAM тұтыну, swap, жиі page fault-тар, кэш тиімділігі (cache hit)

2‑қадам. Жадты қабаттарға бөліп есептеу

Жадты бір көрсеткішпен емес, блоктар бойынша жинақтаңыз.

1. ОС және фондық сервистер. Қазіргі заманғы сервер үшін бұл әдетте ондаған гигабайт: драйверлар, мониторинг және антивирустықты ескеріңіз. Бұл бөлімді «нақты жеткілікті» деп есептемеңіз.

2. ERP қосымша. Бұл белсенді сессиялар мен ауыр операциялар санына байланысты өзгереді. Егер қосымша бөлек серверде болса, есептеу оңайырақ. Егер дерекқормен бірге болса, қосымшаға тым көп жад беріп алмайтыныңызға көз жеткізіңіз.

3. Дерекқор. Әдетте ең ірі тұтынушы: буфер кэш, сұраныс жоспарлары, сұрыптаулар, уақытша кестелер.

4. Кэш пен уақытша пикиге запас. Оның мөлшері жүктеме профиліне тәуелді. Есептік кезеңдер мен ай жабу кезінде запас орташа күнмен салыстырғанда үлкен болуы керек.

3‑қадам. Симптомдар бойынша тексеріңіз

Егер уже swap қолданылып жатса, page fault-тар көбейіп, cache hit төмендесе — бұл жад жетіспеушілігінің айқын белгісі, тіпті орташа тәуліктік көрсеткіштер қалыпты көрінсе де. Пикиді — таңертең, регламенттер, күн соңы, ай жабу — мұқият қадағалаңыз.

4‑қадам. Нәтижені үш деңгейге түсіріңіз

Қосымша шығынсыз және болашаққа шыдамды болу үшін үш мән қалдырыңыз:

• минимум: жүйе жұмыс істейді, бірақ пиктерге сезімтал
• комфорт: пикте свопсыз қалыпты жылдамдық
• запас 12–24 айға: дерекқор өсімі, жаңа есептер, жаңа қолданушылар

Мысал: 250 белсенді қолданушы, дерекқор 1,5 ТБ және тұрақты ауыр есептер. Қолданыстағы машина ай жабу кезінде swap-қа өтеді. «Комфорт» — дерекқордың негізгі жұмыс жиынтығы кэшке сыйып, қосымшаға сессиялар мен фондық тапсырмаларға тұрақты жад қалғанда басталады, плюс пики үшін запас.

NUMA қысқаша: неге екі сокетте баяу болуы мүмкін

NUMA — екі процессорлы серверлерде (және кейбір қуатты бір процессорлы жүйелерде) жады физикалық түрде процессор сокеттері бойынша бөліну ерекшелігі. Қарапайым тілмен: әр CPU-да оған тікелей қосылған «өз» жады бөлігі бар.

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

«Жады сокетке бекітілген» дегеннің практикалық мағынасы: егер серверде жалпы 512 ГБ болса да, бұл 256 ГБ CPU0-да және 256 ГБ CPU1-де болуы мүмкін. Егер дерекқор кэші мен жұмыс деректері екі сокетке шашылып, басты процестер тең бөлінбесе, кейбір операциялар тұрақты түрде қашықтағы жадқа ұшырайды.

NUMA көбіне тек жоғары жүктемеде көрінеді. Пайдаланушылар аз және кэшттер локалдық болғанда бәрі қалыпты көрінеді. Пикиде (ай жабу, көп транзакциялар, есептер) ОС жоспарлаушысы ағындарды белсенді түрде тасымалдайды, кэшттер өседі және қашықтан қолжетімділіктер көбейіп кетеді.

Көп жағдайда NUMA кедергі болмайды, егер:

• бір процессорлы сервер қолданылса
• кіші ERP және дерекқор бір сокет жадында сенімді орналасса
• жеңіл сценарийлер, ауыр аналитикасыз және үлкен параллелизмсіз жұмыс болса

Егер сіз үлкен кэштер мен параллель жүктемесі бар ERP мен дерекқорға сервер таңдап жатсаңыз, NUMA-ны конфигурация кезеңінде ескерген дұрыс. Көп жағдайда әр сокетке жеткілікті RAM қамтамасыз етіп, модульдердің дұрыс орналасуын ұйымдастырған тиімдірек, чем бірдей суммарды ядроларға аңшылық.

NUMA кедергі көрсететін белгілер

Ең жиі көріністері:

• сол қолданушылар санында сұраныстардың кідірістерінің өсуі
• CPU-лардың теңсіз жүктелуі: бір сокет қатты жүктеліп, екіншісі босқа тұр
• жүктеме өсімінен кейін өнімділіктің «саты тәрізді» өзгерістері
• қайта жүктегеннен кейін уақытша жақсару (жады мен ағындардың қайта орналастырылуы)

Бұл диск проблемаларымен шатастырмау маңызды: NUMA кезінде диск қалыпты болуы мүмкін, ал баяулар қашықтағы жадқа қатынаудан келеді.

Қарапайым баптаулармен не істеуге болады

Көп жағдайда келесі шаралар көмектеседі:

• жадты сокеттер мен каналдар бойынша симметриялы орнату
• BIOS-тың жергілікті жадқа әсер ететін экспериментальды режимдерін қолданбау (егер оларды тестілеп көрмеген болсаңыз)
• СУБД-ны негізгі кэштің RAM-ға сыйуын қамтамасыз ете отырып баптау
• жүктемені сынақтан өткізіп, сокеттер бойынша тең жүктелуді және swap болмауын тексеру

Екі сокетте модульдердің қате орналасуы немесе ағындардың кездейсоқ бөлінуі қымбат CPU керек деген сезім бере алады, бірақ мәселе ядроларда емес.

Ядролар мен жадтың теңгерімі: CPU-ға артық төлем жасаудан қалай сақтану

Үлкен дерекқорлы ERP-да ядролар қосу жиі мағынасыз — егер RAM өспесе. Жүйе баяулауының себебі процессордың әлсізтігі емес, деректердің жадыға сыймауы болып табылады: дискке жиі оқу орын алып, жауап уақыты күрт ұзаруы мүмкін.

Не керектігін түсіну үшін шағым түскен сәттегі картинаны қараңыз, тәуліктік орташа мәндерге емес:

• CPU-жүктелген: CPU-дың жүктемесі ұзақ уақыт жоғары, тапсырмалар кезегі өседі, ал бос RAM әлі көп
• жад-упер: RAM көшелі түрде толы, жадқа қысым немесе swap бар, ал CPU шамадан тыс жүктелмеген
• I/O-упер (жад жетіспеу салдарынан): есептер мен жаппай операциялар кезінде дискілік белсенділік күрт өседі
• параллелизм теңсіздігі: бір-екі ағын үнемі тығыз, қалғандары тыныш (бұл көбіне блокировкалар немесе бір ағынды бөліктер)

Сосын маңызды тек «ядра мен RAM» емес, жадтың қалай қосылғаны. Қазіргі платформада жад өнімділігі модуль жиілігі мен каналдар санына тәуелді. Қарапайым ереже: каналдарды көбірек толтырып, орташа көлемдегі модульдерді пайдаланған жақсы, чем екі үлкен модуль салып, артық каналдарды бос қалдыру.

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

Белгілі бюджет шегінде басымдықтар әдетте мынадай: алдымен қажетті RAM көлемін запасымен қамтамасыз етіңіз, содан кейін каналдарды дұрыс толтырыңыз, сосын ERP-дың нақты параллелизм деңгейіне сәйкес CPU-ды таңдаңыз.

Типтік компанияға есеп мысалы: цифрлардан конфигурацияға

Мысал етіп алайық: 220 қызметкер, олардың 140-ы бір уақытта ERP-да жұмыс істейді. Пикте (10:30–12:00) келісімдер, проводкалар және құжаттарды басып шығару жүрсе, 17:30-да бухгалтерия есептерді іске қосады. ERP және дерекқор бір серверге орнатылған.

Жадты қабаттар бойынша есептейміз. Мысалы, дерекқор есептер дискіге шықпас үшін шамамен 180–220 ГБ кэш ұстайды. Қосымша логика мен сервистерге тағы 30–50 ГБ, ОС және қызметтерге 10–20 ГБ қажет. Өсу мен пикиге 25–35% запас қосамыз.

Жалпы жуық есеп: 220 ГБ (ДҚ кэші) + 40 ГБ (қосымша) + 15 ГБ (ОС) = 275 ГБ. 30% запас қосқанда шамамен 360 ГБ мақсатты RAM шығады. Практикада бұл 384 ГБ (модульдерге ыңғайлы қадам) немесе 512 ГБ болады, егер қолданушылар тез өседі немесе ауыр аналитика күтілсе.

Сосын екі процессор керек пе деп шешеміз. Егер бір процессорда ядро мен жад бойынша жеткілікті мүмкіншілік болса — 1-сокеттеу оңайырақ: NUMA мәселелері аз және баптау оңай. Ал 512 ГБ және одан жоғары қажет болса немесе қосымша PCIe жолдары мен слоттар маңызды болса — екі сокет логикалық шешім. Бұл жағдайда жадты екі процессорға тең бөлу және жүктеменің бір сокетте «жақта қалмауын» қадағалау — негізгі ереже.

Пилотты сынау қысқа, бірақ шынайы болуы тиіс: 1–2 сағат нақты пике және бөлек типтік есептің жүгіруі. Тест кезінде RAM тұтыну, жадқа қысым, кэш промахтары салдарынан дискілік белсенділік, CPU-дың ядролар бойынша жүктелуі мен NUMA-узелдер бойынша теңдігі, сондай-ақ 2–3 негізгі операцияның орындалу уақыты жазылса пайдалы.

ERP серверін таңдауда жиі кездесетін қателіктер (жад маңызды болғанда)

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

Көпшілік дерекқор өлшемін емес, кэште жұмыс істейтін жұмыс жиынтығын, уақытша кестелер мен сұрыптауларға қажет жадты бағаламайды. Сондықтан «впритык» конфигурация күндіз жұмыс істеп, пики кезінде күрт құлайтын болады.

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

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

Соңғысы — екі сокеттегі NUMA-ны елемеу. Осы кезде кешкі есептер бүгін тез жүрсе, ертең ұқсас жүктемеде баяулау мүмкін.

Сатып алу алдында және эксплуатацияға енгізер алдында қысқа чек‑тізім

Сатып алу алдында

Пикидегі жүйе мінез-құлқына (күн жабу, есептер, жаппай операциялар) сүйеніңіз, орташа мәндерге емес.

• Жад: піктегі RAM тұтынуын тіркеңіз, swap бар ма тексеріңіз, сервер пикте үнемі жад тапшылығына түспеуі үшін запас қойыңыз.
• Процессор: тек жүктемені ғана емес, CPU кезегі мен жадыға қатысты күту белгілерін қараңыз.
• Өсу: бір жылда қанша қолданушы мен деректер қосылады және қандай ауыр есептер енгізілуі мүмкін екенін бағалаңыз.
• NUMA: егер екі сокет жоспарланған болса, алдын ала шешіңіз — ERP мен ДҚ бір серверде бола ма және ресурстарды қалай бөлу жоспарланған.
• Жадтың орналасуы: модульдерді сокеттар мен каналдар бойынша симметриялы орнатуды растаңыз.

Эксплуатацияға енгізер алдында

• Сокеттер бойынша жүктеменің теңдігін тексеріңіз: бір сокет қатты жүктеліп, екіншісі бос тұрған болса, бұл NUMA немесе баптау проблемасына нұсқайды.
• Пикте swap белсенді емес және жадта кенет азаю жоқтығына көз жеткізіңіз.
• Продуктивке жүктемеден бұрын негізгі көрсеткіштерді алыңыз: негізгі операциялардың орындалу уақыты, орташа және пиковый кідіріс. Сосын ресурстар проблемаларын желі немесе конфигурация мәселелерінен ажырату оңайырақ болады.
• Кеңейту жоспарын бекітіңіз: қандай слоттар жад пен дискілер үшін бос қалуы тиіс және жүктеме өссе не істеу (RAM қосу, ERP пен ДҚ-ны бөлу, басқа сервер классына өту).

Келесі қадамдар: талапты рәсімдеу және дұрыс таңдау жасау

RAM бағасы мен NUMA тәуекелдері түсінікті болса, оны қысқа талаптар құжатына айналдырыңыз. Бұл ІТ, қаржы және жеткізуші арасында бірдей түсінік береді және ядроларға артық төлеу қаупін азайтады.

Қысқа бір бетте көрсетіңіз:

• мақсатты RAM көлемі және 12–24 айға өсу үшін запас, сондай‑ақ кеңейту талаптары
• CPU схемасы (1 немесе 2 сокет), күтілетін активті ядролар саны және лицензия талаптары
• орын талаптары: шкафтағы орын, қуат, салқындату, шу
• сақтау және желі талаптары: дерекқор қайда орналасады, қажетті IOPS/өткізу қабілеттілігі, порттар саны
• қолжетімділік пен қызмет көрсету талаптары: RAID, қосалқы БП, ыстық алмастыру, рұқсат етілген тоқтау терезесі

Әрине, бұдан бөлек 2–3 «стоп-фактор» анықтаңыз, оларды бұзуға болмайды (мысалы, RAM X ГБ-тан төмен болмайды немесе лицензия себебінен ядроларды Y-дан артық ұлғайтуға болмайды).

Пилот пен табыс критерийлерін сатып алудан бұрын ойластырыңыз: 3–4 өлшенетін көрсеткіш (негізгі есептердің құру уақыты, операцияны орындау уақыты, максимум бір уақытта қолданушылар саны, свопсыз тұрақтылық және пиковый уақыттағы кенет төмендеу болмауы). Тестке нақты сценарийлерді енгізіңіз: ай жабу, жаппай проводкалар, ауыр сұраныстар.

Егер бір мердігер барлық жұмыстарды орындауын қаласаңыз, Қазақстанда мұны көбінесе GSE.kz арқылы жүзеге асырады: компанияда S200 сериялы серверлері бар және ERP мен СУБД үшін инфрақұрылым жобалау тәжірибесі, соның ішінде жадты таңдау және жүктеме бойынша тексеру бар.