Pumili ng memory para sa operating system, persistenteng mga serbisyo at makatotohanang concurrency na may headroom. Pumili ng CPU pagkatapos sukatin kung aling mga gawain ang abala, kung tumatakbo ang mga ito nang parallel at kung anong mga pagkaantala ang aktwal na nararanasan ng mga user.
Ilarawan nang hiwalay ang normal na trabaho at abalang trabaho
Ang bilang ng bisita lamang ay isang mahinang input sa sizing. Ang isang request ay maaaring maghatid ng cached na file habang ang isa ay bumubuo ng ulat o nag-query sa maraming table. Ilista ang mga web worker, database, cache, queue consumer at mga gawain sa pagpapanatili na magbabahagi ng VPS. Ilarawan ang normal na concurrency at ang pinaka-abalang inaasahang operasyon. Isama ang mga naka-iskedyul na export, pag-update ng package at deployment sa halip na ituring ang mga ito bilang hindi nakikitang aktibidad sa background.
Para sa isang umiiral na proyekto, mangolekta ng isang representatibong panahon na may kasamang abalang window. Itala ang mga oras ng tugon at error kasama ng paggamit ng resource. Para sa isang bagong proyekto, gumawa ng maliit na pagsubok na may makatotohanang hugis ng request at laki ng data. Ang iyong paunang pagtatantya ay hindi perpekto; ang kapaki-pakinabang na layunin ay isang dokumentadong panimulang punto na maihahambing mo sa nasusukat na pag-uugali pagkatapos ng paghahatid.
Buuin ang badyet sa memory bago magdagdag ng mga proseso
Ang pangangailangan sa memory ay nagmumula sa system, persistenteng mga serbisyo ng aplikasyon, paggamit ng bawat worker at pansamantalang mga operasyon. Ang pagpaparami ng footprint ng isang worker sa isang planong concurrency ay isang magaspang na kasangkapan sa pagpaplano, hindi isang garantiya, dahil ang shared memory at mga cache ay nagpapakumplikado sa kabuuan. Obserbahan ang aktwal na mga proseso sa ilalim ng load. Mag-iwan ng sapat na espasyo upang ang isang gawain sa pagpapanatili ay hindi pilitin ang aplikasyon na makipagkumpitensya para sa bawat natitirang page.
Ang mga setting ng database ay maaaring magparami ng paggamit ng memory nang hindi inaasahan. Dinodokumento ng PostgreSQL na ang work_mem ay nalalapat sa mga operasyon ng query, at ilang operasyon o sesyon ang maaaring tumakbo nang sabay. Ang isang setting na mukhang katamtaman sa paghihiwalay ay maaaring may mas malaking epekto sa system. Basahin ang sariling gabay ng iyong database, subukan ang makatotohanang concurrency at iwasan ang paglalaan ng bawat inaanunsyong gigabyte sa isang cache.
Ibahin ang paggamit ng CPU mula sa kapaki-pakinabang na parallelism
Ang bilang ng processor ay nagsasabi sa iyo kung gaano karaming execution resource ang ipinapakita sa guest, hindi kung gaano kahusay magagamit ng iyong software ang mga ito. Ang isang abalang thread ay maaaring maglimita sa isang aplikasyon habang ang ibang core ay tahimik. Ang pagdaragdag ng worker ay makakatulong sa mga independiyenteng request, ngunit maaari rin nitong dagdagan ang contention sa database at pangangailangan sa memory. Suriin ang modelo ng concurrency ng aplikasyon bago ipagpalagay na ang doble ng bilang ng core ay gumagawa ng doble ng throughput.
Ang KVM ay nagbibigay sa mga virtual machine ng sarili nilang virtual hardware. Hindi nito ginagawang magkaparehong benchmark sa lahat ng host at henerasyon ng processor ang bawat label ng vCPU. Ihambing ang nakalistang modelo ng CPU at mga tuntunin sa paglalaan kung available, pagkatapos suriin ang serbisyo gamit ang sarili mong workload. Iwasan ang paggawa ng konklusyon sa pagbili mula sa isang maikling sintetikong score na hindi kahawig ng aplikasyon.
Hanapin ang pressure at paghihintay, hindi lamang ang mga average
Ang isang system ay maaaring maging mabagal nang hindi nagpapanatili ng mataas na average na porsyento ng CPU. Ang mga proseso ay maaaring maghintay sa storage, pagbawi ng memory o ibang serbisyo. Ang Pressure Stall Information ng Linux kernel ay naglalantad ng impormasyon sa paghinto ng CPU, memory at I/O sa mga sinusuportahang system. Ang mga senyales na ito ay makakatulong na tukuyin ang contention sa resource kasama ng normal na mga metric ng paggamit at timing ng aplikasyon.
Basahin ang mga metric nang magkasama. Ang tuloy-tuloy na pressure sa memory, pag-swap, nabigong paglalaan at mabagal na request ay tumutukoy sa ibang interbensyon kaysa sa isang abalang compute worker. Ang paghihintay sa storage ay maaaring magbigay-katwiran sa mga pagbabago sa query o ibang disk profile. Ang isang panlabas na pagkaantala ng API ay hindi maaayos sa pamamagitan ng pagdaragdag ng lokal na RAM. Ipaliwanag ang naobserbahang hadlang bago pumili kung aling resource ang dadagdagan.
| Naobserbahang pag-uugali | Tanong na sisiyasatin | Posibleng susunod na hakbang |
|---|---|---|
| Isang thread na abala, ekstrang core na tahimik | Maaari bang tumakbo ang gawaing ito nang parallel? | Pagbutihin ang gawain o baguhin ang disenyo ng worker |
| Pressure sa memory habang may ulat | Ilan ang nagsasapawang operasyon? | Limitahan ang concurrency o magdagdag ng nasubok na headroom |
| Mabagal na request na may I/O wait | Aling mga pagbasa o pagsulat ang naantala? | Suriin ang mga query at pag-uugali ng storage |
| CPU at memory mababa, mabagal ang mga request | May dependency bang nagpapabagal sa mga tugon? | Sukatin ang mga downstream call |
Isang halimbawa ng pagpaplano na may tahasang mga palagay
Isipin ang isang maliit na aplikasyon na may dalawang web worker, isang database at isang queue consumer. Sinusukat ng team ang mga serbisyong iyon sa mga ordinaryong request at isang gawain sa pagbuo ng ulat. Natuklasan nito na ang pagpapahintulot ng apat na ulat nang sabay ay nagpapataas ng pangangailangan sa memory nang husto habang nagpapabagal sa normal na trapiko. Sa halip na agad na bilhin ang pinakamalaking plano, nililimitahan nito ang concurrency ng ulat at muling sinusukat ang resulta.
Kung ang inayos na workload ay nangangailangan pa rin ng mas maraming memory, ang upgrade ay sumasagot na ngayon sa isang naobserbahang kinakailangan. Kung ang queue ay nananatiling CPU-bound at ang mga independiyenteng trabaho ay maaaring tumakbo nang sabay, ang mas maraming execution resource ay maaaring angkop. Ang mga ito ay halimbawang desisyon, hindi mga bilang ng pagganap para sa mga plano ng SwissOctet. Panatilihin ang sarili mong mga pagsukat at hadlang kasama ng piniling configuration.
Mag-iwan ng malinaw na landas para sa susunod na pagsukat
Tukuyin ang mga palatandaan na magti-trigger ng review: pagkasira ng oras ng pagtugon, paulit-ulit na pressure sa memory, lumalaking pila o nagbago ang workload. Panatilihing magaan ang monitoring para hindi ito maging bagong bottleneck. Muling suriin pagkatapos magdagdag ng feature o malaking dataset, at iwasan ang paulit-ulit na pag-upgrade kung ang tunay na problema ay isang walang hanggang proseso o mabagal na query.
Ang mga VPS na pamilya ng SwissOctet ay naglalantad ng CPU at mga detalye ng memory at piling opsyon sa resource. Basahin ang huling configuration pagkatapos magdagdag ng mga extra, kasama ang panahon ng pagsingil at kabuuan. Kumpirmahin ang mga kaayusan sa pag-upgrade sa live na operator bago umasa sa mga ito. Ang kapaki-pakinabang na laki ng VPS ay ang tumatakbo sa nasusukat na workload na may makatwirang headroom at nauunawaang susunod na hakbang.
Ang iyong praktikal na checklist.
- I-inventory ang mga serbisyo at gawaing maintenance.
- Sukatin ang concurrency sa normal at abalang panahon.
- I-budget ang persistent at temporary na memory.
- Suriin kung ang gawain ng CPU ay maaaring tumakbo nang parallel.
- Ihambing ang pressure, utilisation at mga timing ng application.
- Tukuyin kung kailan susuriin ang configuration.
Ang mga detalyeng mahalaga.
Dapat ko bang i-size ang VPS batay sa buwanang bisita?+
Gamitin ang bilang ng bisita bilang konteksto, pagkatapos sukatin ang pagiging kumplikado ng request, concurrency, laki ng data at background na gawain. Ang magkaparehong bilang ng bisita ay maaaring lumikha ng magkaibang load.
Palaging pinapabilis ba ng mas maraming RAM ang isang serbisyo?+
Hindi. Nakakatulong ito kapag ang memory ay hadlang o nagpapagana ng kapaki-pakinabang na caching, ngunit hindi nito nareresolba ang bawat CPU, storage o panlabas na dependency na pagkaantala.
Doble ba ang performance kapag doble ang bilang ng vCPU?+
Hindi. Ang parallelism, katangian ng processor, contention at disenyo ng application ang tumutukoy kung gaano karaming dagdag na kapasidad ang kapaki-pakinabang.
Pumunta sa pinagmulan.
Sinusuportahan ng mga sangguniang ito ang mga teknikal na konsepto sa gabay na ito. Sundin ang kasalukuyang dokumentasyon bago baguhin ang isang production system.
- Linux kernel: Pressure Stall Information docs.kernel.org
- PostgreSQL: Pagkonsumo ng Resource www.postgresql.org
- Proyekto ng KVM: Kernel Virtual Machine www.linux-kvm.org
Editorial guidance ni SwissOctet. Ang mga halimbawa ay ilustratibo. Ang service specifications, available options at contractual conditions ay dapat beripikahin nang hiwalay.