Coding agent VPS-க்கு எவ்வளவு RAM தேவை?

Coding agent VPS-க்கு எவ்வளவு RAM தேவை?

ஒரு repository-ல் எப்போதும் இயங்கிக்கொண்டிருக்கும் ஒரு coding agent-க்கு, ஆரம்பத்தில் 4 GB RAM மற்றும் 2 vCPU போதுமானது. ஒரு language server அல்லது Docker build அந்த session-ல் இணைந்தவுடன், 8 GB RAM மற்றும் 4 vCPU-க்கு மாறவும்; பெரும்பாலான repository-களில் இது முதல் நாளிலேயே தேவைப்படும். Agent process சிறியது என்பதால், உங்கள் சார்பாக அது இயக்கும் toolchain-களே server-ன் வளங்களை முழுமையாகப் பயன்படுத்தும்.

[
  {
    "plan": "Minimum viable",
    "ram_gb": 4,
    "vcpu": 2,
    "disk_gb": 50
  },
  {
    "plan": "Comfortable",
    "ram_gb": 8,
    "vcpu": 4,
    "disk_gb": 100
  },
  {
    "plan": "Team, 4 sessions",
    "ram_gb": 16,
    "vcpu": 8,
    "disk_gb": 200
  }
]

மேலே உள்ள ஒவ்வொரு வரிசையும், model வேறொரு இடத்தில், network வழியாக நீங்கள் அழைக்கும் API-க்கு பின்னால் இயங்குவதாகக் கருதுகிறது. இந்த அனுமானமே server-ன் அளவைத் தீர்மானிக்கிறது, எனவே முதலில் இதை உறுதிப்படுத்திக் கொள்ளவும்.

நீங்கள் agent-ஐ இயக்குகிறீர்களா அல்லது model-ஐ இயக்குகிறீர்களா?

Cloud model-ஐ அழைக்கும் ஒரு coding agent என்பது, shell இணைக்கப்பட்ட ஒரு network client ஆகும். இது கோப்புகளையும் (files) ஒரு திட்டத்தையும் (plan) API-க்கு அனுப்பிவிட்டு, பதிலுக்காகக் காத்திருக்கும்; பின்னர் கோப்புகளைத் திருத்தி, கட்டளைகளை (commands) உள்ளூர் கணினியில் இயக்கும். காத்திருக்கும் நேரத்தில் இது CPU-வை கிட்டத்தட்ட பயன்படுத்துவதில்லை. இதன் நினைவகப் பயன்பாடு (memory) சில நூறு megabytes மட்டுமே; இதனால்தான் ஒரு சாதாரண CPU கொண்ட கணினி இதற்குப் போதுமானது.

Model-ஐ நீங்களே இயக்குவது என்பது முற்றிலும் மாறுபட்ட ஒரு செயல்முறை, அதற்கு வேறுபட்ட வன்பொருள் (hardware) தேவை. Server இயங்கும் வரை model-ன் weights நினைவகத்தில் இருக்க வேண்டும். 7 billion parameter கொண்ட ஒரு model-ஐ 4 bits-க்கு quantise செய்தால், அதற்கு weights-க்காக மட்டும் சுமார் 5 GB தேவைப்படும்; இது context-ன் நீளத்திற்கு ஏற்ப வளரும் key/value cache-க்கு முந்தைய அளவாகும். CPU-வில் மட்டும் இயக்கும்போது, ஒரு shared vCPU வினாடிக்குச் சில tokens-ஐ மட்டுமே உருவாக்கும். ஒரு agent task ஆயிரக்கணக்கான tokens-ஐ உருவாக்கக்கூடும் என்பதால், API மூலம் ஒரு நிமிடத்திற்குள் முடியும் வேலை, உள்ளூர் கணினியில் ஒரு மணிநேரம் வரை ஆகலாம். உங்களுக்கு இதுதான் தேவை என்றால், VRAM (GPU-வில் உள்ள video memory) அளவைக் கணக்கில் கொண்டு, இந்தப் பக்கத்திற்குப் பதிலாக GPU கொண்ட VPS உண்மையில் உங்களுக்கு என்ன வழங்குகிறது என்பதைப் படிக்கவும்.

கீழே உள்ள அனைத்தும் cloud-model பயன்பாட்டிற்கானவை.

நினைவகத்தை உண்மையில் பயன்படுத்துவது எது

[
  {
    "label": "Agent CLI process, idle",
    "typical_mb": 250,
    "peak_mb": 600
  },
  {
    "label": "TypeScript language server",
    "typical_mb": 700,
    "peak_mb": 2000
  },
  {
    "label": "rust-analyzer, large workspace",
    "typical_mb": 1200,
    "peak_mb": 4000
  },
  {
    "label": "Headless Chrome, one tab",
    "typical_mb": 350,
    "peak_mb": 900
  },
  {
    "label": "Node test run, 4 workers",
    "typical_mb": 1600,
    "peak_mb": 3000
  },
  {
    "label": "Docker image build",
    "typical_mb": 800,
    "peak_mb": 2500
  }
]

இவை நடுத்தர அளவிலான திட்டங்களுக்கான பொதுவான தரவுகள். இவற்றை உங்கள் நிரலுக்கான உறுதியான அளவீடாகக் கருதாமல், ஒரு தோராயமான வழிகாட்டியாகக் கொள்ளவும்.

இந்த வரைபடத்தில் 6 வரிசைகள் உள்ளன, மேலும் agent மிகக் குறைந்த நினைவகத்தையே பயன்படுத்துகிறது. இது சும்மா இருக்கும்போது (idle) சுமார் 250 MB நினைவகத்தில் இருக்கும், ஏனெனில் இது ஒரு உரையாடலையும் சிறிய கோப்பு cache-ஐயும் மட்டுமே வைத்திருக்கிறது. ஒரு TypeScript language server குறியீட்டை வரிசைப்படுத்தும்போது (indexing) சுமார் 2000 MB வரை செல்லும், ஏனெனில் இது உங்கள் tsconfig.json-லிருந்து அணுகக்கூடிய ஒவ்வொரு கோப்பிற்கும் ஒரு type graph-ஐ உருவாக்கி, அடுத்த கோரிக்கைக்கு விரைவாகப் பதிலளிக்க அதை நினைவகத்தில் வைத்திருக்கும். rust-analyzer ஒரு பெரிய workspace-ல் இதே காரணத்திற்காக, ஒவ்வொரு crate-க்கும் சேர்த்து பொதுவாக 4000 MB-ஐத் தாண்டும்.

Headless Chrome உலாவி மற்றும் ஒரு tab-க்கு சுமார் 350 MB செலவாகும், மேலும் ஒவ்வொரு கூடுதல் tab-ம் ஒரு தனி operating system process ஆகும். நான்கு workers-உடன் இயங்கும் ஒரு Node test, நான்கு Node process-களை உருவாக்குவதால், அது சுமார் 3000 MB வரை உச்சத்தை எட்டும். ஒரு Docker image build சுமார் 2500 MB வரை செல்லும், ஏனெனில் build நடக்கும்போது container-க்குள் உங்கள் திட்டத்தின் compiler இயங்கும், அதே நேரத்தில் daemon அடுக்குகள் (layers) எழுதும்.

sudo apt update && sudo apt install -y time
/usr/bin/time -v -o /tmp/build.rusage npm run build
grep "Maximum resident set size" /tmp/build.rusage

free -h-ன் available நெடுவரிசையைப் பார்க்கவும், free நெடுவரிசையை அல்ல. Linux தனது உபரி நினைவகத்தை disk cache-க்காகப் பயன்படுத்தும், எனவே ஆரோக்கியமான ஒரு கணினியில் free மிகக் குறைவாகவே இருக்கும், அது எதையும் உணர்த்தாது. available என்பது ஒரு புதிய process உண்மையில் பெறக்கூடிய நினைவகத்தின் அளவாகும்.

செயல்படக்கூடிய மூன்று கட்டமைப்புகள்

குறைந்தபட்சத் தேவை: 4 GB RAM, 2 vCPU, 50 GB disk. ஒரு agent session, ஒரு repository, ஒரு language server மற்றும் நீங்கள் காத்திருக்கத் தயாராக இருக்கும் build-கள். இந்தத் தரம் செயல்படும், ஆனால் ஒரு பெரிய test run-ம் indexing language server-ம் ஒரே நேரத்தில் இயங்கும்போது, இது out-of-memory killer-ஆல் நிறுத்தப்படலாம். Swap-ஐச் சேர்த்து, உங்கள் build worker-களின் எண்ணிக்கையைக் கட்டுப்படுத்துங்கள்.

வசதியான தரம்: 8 GB RAM, 4 vCPU, 100 GB disk. ஒரு agent, அதனுடன் Docker, சோதனைகளுக்கான headless browser மற்றும் ஒரு build spike-ஐக் கையாளும் கூடுதல் திறன். பெரும்பாலான தனிப்பட்ட developer-கள் இந்தத் தரத்தைத் தேர்வு செய்ய வேண்டும். vCPU எண்ணிக்கையை இருமடங்காக்குவது build காத்திருப்பு நேரத்தை ஏறக்குறைய பாதியாகக் குறைக்கும்; இது memory-ஐ விட அதிக மாற்றத்தை ஏற்படுத்தும்.

குழுத் தரம்: 16 GB RAM, 8 vCPU, 200 GB disk. நான்கு ஒரேநேர sessions, ஒவ்வொன்றுக்கும் தனித்தனி checkout மற்றும் toolchain. உச்சகட்டத் தேவைக்கு ஏற்ப அளவிடுங்கள், ஏனெனில் நான்கு idle agent-கள் கிட்டத்தட்ட எந்தச் செலவையும் ஏற்படுத்தாது, ஆனால் நான்கு test run-கள் ஒரே நேரத்தில் நடக்கும்போது அவை மேலே உள்ள peak column-ஐ விட நான்கு மடங்கு செலவை ஏற்படுத்தும்.

ஆகஸ்ட் 2026 நிலவரப்படி, முதல் வரிசையிலிருந்து கடைசி வரிசைக்கு மாறுவது, வருடாந்திர VPS கட்டணத்தில் மாத விலையை விட ஏறக்குறைய நான்கு மடங்கு அதிகமாகும்: தொடக்கத்தில் ஒற்றை இலக்க டாலர்கள், உச்சத்தில் பத்து டாலர்கள். நீங்கள் திட்டமிடுவதற்கு முன் தற்போதைய விலைப் பட்டியலைச் சரிபார்க்கவும், ஏனெனில் அந்த எண்கள் மாறக்கூடும். server-ன் விலை அரிதாகவே அதிகமாக இருக்கும். தினமும் agent-ஐப் பயன்படுத்துபவர்களுக்கு, model API கட்டணம் server கட்டணத்தை விரைவாகத் தாண்டிவிடும், எனவே agent எவ்வளவு செலவு செய்ய அனுமதிக்கப்படுகிறது என்பதைக் கட்டுப்படுத்துங்கள் (cap what the agent is allowed to spend), server-ன் அளவைக் குறைக்கும் முன் இதைச் செய்யவும். build-ஐப் பொறுத்தவரை, VPS-ல் coding agent-ஐ இயக்குவதற்கான வழிமுறை (the walkthrough for running a coding agent on a VPS) கணக்கு அமைப்பு மற்றும் நீங்கள் disconnect செய்த பிறகும் session-ஐத் தொடர்ந்து வைத்திருப்பது குறித்து விளக்குகிறது.

RAM தீரும் முன்பே disk ஏன் தீர்ந்துவிடுகிறது

[
  {
    "label": "Ubuntu 24.04 base and toolchain",
    "typical_gb": 6
  },
  {
    "label": "One JS monorepo checkout",
    "typical_gb": 3
  },
  {
    "label": "node_modules across 3 branches",
    "typical_gb": 4
  },
  {
    "label": "Docker images and build cache",
    "typical_gb": 20
  },
  {
    "label": "Agent logs and journal, 90 days",
    "typical_gb": 2
  }
]

இந்த வரிசைகளை எல்லாம் கூட்டினால், நீங்கள் ஒரு வரி code கூட எழுதாததற்கு முன்பே 50 GB disk கிட்டத்தட்ட நிரம்பிவிடும். இதில் மிகப்பெரிய பங்கு Docker-க்கு உரியது, இது சுமார் 20 GB வரை இருக்கும். ஏனெனில், நீங்கள் கட்டளையிடும் வரை BuildKit ஒவ்வொரு build-ன் இடைநிலை layer-களையும் அப்படியே வைத்திருக்கும்.

docker system df
docker builder prune --filter until=168h

docker system df ஒவ்வொரு வகைக்கும் எவ்வளவு இடத்தை மீட்க முடியும் என்பதைக் காட்டும், எனவே இதைச் செய்வதற்கு முன்பும் பின்பும் இயக்கவும். until=168h filter ஒரு வாரத்திற்கு முந்தைய build cache-ஐ நீக்கிவிட்டு, இந்த வாரத்தின் cache-ஐ மட்டும் வைத்திருக்கும்; இதுவே உங்கள் நேரத்தை மிச்சப்படுத்தும் cache ஆகும். docker image prune -a இன்னும் தீவிரமாகச் செயல்பட்டு, எந்த container-லும் பயன்படுத்தப்படாத அனைத்து image-களையும் நீக்கிவிடும், எனவே அடுத்த build-ன் போது மீண்டும் pull செய்ய வேண்டியிருக்கும் என்பதை நினைவில் கொள்ளவும்.

Node projects விசித்திரமான முறையில் தோல்வியடையும். npm install லட்சக்கணக்கான சிறிய கோப்புகளை உருவாக்கும், இதனால் df -h இன்னும் பல gigabytes காலியாக இருப்பதாகக் காட்டினாலும், filesystem-ன் inodes தீர்ந்துவிடலாம். அப்போது, பாதி காலியாகத் தெரியும் disk-ல் எழுதும் செயல்பாடு No space left on device பிழையுடன் தோல்வியடையும்.

df -h /
df -i /

IUse% 100 என்று காட்டினால், நீங்கள் தற்போது பயன்படுத்தாத branch-களின் node_modules கோப்பகங்களை நீக்கவும், அல்லது pnpm-க்கு மாறவும். இது ஒவ்வொரு package version-ஐயும் ஒருமுறை மட்டும் சேமித்து, ஒவ்வொரு project-க்கும் hard-link மூலம் இணைக்கும்.

Logs கவனிக்கப்படாத ஒரு காரணி. எப்போதும் இயங்கும் agent ஒன்று session விவரங்களை எழுதிக்கொண்டே இருக்கும், மேலும் systemd journal இயல்பாகவே disk-ன் ஒரு பகுதியை ஆக்கிரமித்து வளரும்.

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=200M
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail

/etc/systemd/journald.conf-ல் SystemMaxUse=200M-ஐ அமைக்கவும், பின் sudo systemctl restart systemd-journald-ஐ இயக்கி அந்த வரம்பை நிரந்தரமாக்கவும். ஏனெனில், ஒருமுறை மட்டும் செய்யும் vacuum இன்றைய இடத்தை மட்டுமே மீட்டுத்தரும்.

Swap: இது எதை வழங்குகிறது, எதை மறைக்கிறது

Swap சேர்ப்பது பயனுள்ளது, ஏனெனில் இது ஒரு சிறிய நினைவகப் பற்றாக்குறையை (overshoot) செயலிழக்கச் செய்வதற்குப் பதிலாக, மெதுவான செயல்பாடாக மாற்றுகிறது. RAM-ன் அளவில் பாதியை, அதிகபட்சம் 4 GB வரை இதற்காக ஒதுக்கலாம். ஒரு build box-க்கு இதைவிட அதிகமாகச் செல்வதற்குத் தேவையான காரணங்கள் குறைவு.

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
swapon --show

swapon --show இப்போது நீங்கள் குறிப்பிட்ட அளவில் /swapfile-ஐக் காட்ட வேண்டும். /etc/fstab வரி இல்லையென்றால், அடுத்த reboot-க்குப் பிறகு swap மறைந்துவிடும் மற்றும் அந்த box அமைதியாக அதன் பழைய செயல்பாட்டிற்குத் திரும்பிவிடும். fallocate-க்கு Operation not supported என்று பதில் கிடைத்தால், sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 மூலம் கோப்பை உருவாக்கி, chmod-லிருந்து தொடரவும்.

echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

குறைந்த swappiness மதிப்பு, kernel-ஐ disk cache-ஐ மீட்டெடுக்கத் தூண்டுகிறது. இது program memory-ஐ disk-க்குத் தள்ளுவதற்கு முன்பே நடப்பதால், language server-ன் வேகம் குறையாமல் இருக்கும்.

இப்போது swap மறைக்கும் விஷயத்தைப் பார்ப்போம். ஒரு பணிக்கு box-ல் உள்ளதை விட அதிக நினைவகம் தேவைப்படும்போது, உங்கள் build-ஐ இயக்குவதற்குப் பதிலாக, kernel தனது நேரத்தை RAM மற்றும் disk-க்கு இடையே பக்கங்களை (pages) நகர்த்துவதில் செலவிடும். எதுவும் செயலிழக்காது. ஆனால் அனைத்தும் மிக மெதுவாகச் செயல்படும், CPU சும்மா இருந்தாலும் load average உயரும்.

vmstat 1 10

si மற்றும் so நெடுவரிசைகளில் நிலையான பூஜ்ஜியமற்ற எண்கள் இருந்தால், தொடர்ந்து swapping நடக்கிறது என்று அர்த்தம். இதற்குத் தீர்வு concurrency-ஐக் குறைப்பது அல்லது அதிக RAM சேர்ப்பது மட்டுமே; ஒருபோதும் அதிக swap சேர்ப்பது தீர்வாகாது. சிறிய box-களில் sudo apt install -y zram-tools மூலம் RAM-ல் சுருக்கப்பட்ட swap-ஐப் பயன்படுத்தலாம், இதை /etc/default/zramswap-ல் சரிசெய்யலாம். இது swap file-ஐ விட மிக வேகமானது. இது RAM-ஐச் சேமிக்க RAM-ஐயே பயன்படுத்துவதால், இது cold pages-க்கு உதவும், ஆனால் உண்மையான working memory தேவைப்படும் build-க்கு உதவாது.

உங்கள் coding agent ஏன் முடங்கியது போலத் தோன்றுகிறது

சிறிய agent box-களில் தவறாகப் புரிந்துகொள்ளப்படும் மிக முக்கியமான தோல்வி இது. ஒரு command எந்த முடிவையும் தராமல் agent காத்திருக்கும்போது, session முடங்கியது போலத் தோன்றும். kernel-ன் out-of-memory (OOM) killer அந்த process-ஐக் கொன்றதே இதற்குக் காரணம். அதற்கு SIGKILL கிடைத்ததால், அதனால் பிழைச் செய்தியை அச்சிடவோ, log-ஐப் பதிவு செய்யவோ அல்லது agent-க்கு என்ன நடந்தது என்று தெரிவிக்கவோ முடியவில்லை. agent-க்கு எந்த முடிவும் கிடைக்காததால், அது முடங்கியது போலத் தெரிகிறது.

kernel இதைத் தெளிவாகப் பதிவு செய்கிறது:

sudo dmesg -T | grep -iE "out of memory|killed process"
sudo journalctl -k -b | grep -i oom

உண்மையான பதிவு இப்படி இருக்கும்:

[Thu Aug  6 11:02:14 2026] Out of memory: Killed process 4711 (node) total-vm:4210880kB, anon-rss:3820104kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:8236kB oom_score_adj:0

anon-rss என்பது அந்த process இறந்தபோது அது பயன்படுத்திய நினைவகத்தின் அளவு. எந்த process தேர்ந்தெடுக்கப்பட்டது என்பதைக் கவனியுங்கள்: kernel பெரும்பாலும் அதிக நினைவகத்தைப் பயன்படுத்தும் process-ஐயே குறிவைக்கும். எனவே, box-ன் நினைவகத்தை முழுமையாகப் பயன்படுத்திய build-ஐ விட, language server அல்லது agent-ஐ அது கொன்றுவிடும். இதனால்தான் "agent பழுதாகிவிட்டது" என்ற தோற்றம் ஏற்படுகிறது.

Docker-க்குள் இதே நிகழ்வு இன்னும் தெளிவாகத் தெரியும். container 137 என்ற exit code-உடன் வெளியேறும்; இது 128 மற்றும் signal 9-ன் கூட்டுத்தொகை ஆகும்.

docker ps -a
docker inspect "$(docker ps -lq)" | grep -i oomkilled

"OOMKilled": true, container தானாக crash ஆகாமல், அதன் நினைவக வரம்பை (memory limit) எட்டியதை உறுதிப்படுத்துகிறது.

இதற்கான தீர்வு, அதிக நினைவகத்தைப் பயன்படுத்தும் command-க்கு ஒரு வரம்பை நிர்ணயிப்பதாகும். அப்போது agent-க்கு பதிலாக அந்த build மட்டுமே நின்றுவிடும்:

systemd-run --user --scope -p MemoryMax=4G -- npm run build

இப்போது build 4 GB-ல் நிறுத்தப்படும், agent தொடர்ந்து இயங்கும். இதனால், மர்மமான முறையில் முடங்குவதற்குப் பதிலாக, ஒரு சாதாரண தோல்வியடைந்த command-ஆக இது மாறும், மேலும் தெளிவான exit code-ஐயும் பெறலாம். இதற்கு systemd user session தேவை, எனவே நீங்கள் SSH மூலம் மட்டுமே அணுகும் box-ல் loginctl enable-linger $USER-ஐ இயக்கவும். MemoryHigh= அந்த process-ஐக் கொல்வதற்குப் பதிலாக, நிர்ணயிக்கப்பட்ட வரம்பிலேயே கட்டுப்படுத்தும் (throttle). மெதுவாகவாவது build முடிவடைய வேண்டும் என்று நீங்கள் விரும்பினால், இதுவே சிறந்த வழியாகும்.

Compose memory limits மூலம் ஒருமுறை கட்டுப்படுத்துதல்

Agent-ன் கருவிகள் container-களில் இயங்கினால், ஒவ்வொரு முறையும் அது செயல்படும் வகையில் Compose கோப்பிலேயே அதன் உச்ச வரம்பை (ceiling) அமைக்கவும்.

services:
  agent:
    image: node:22-bookworm
    deploy:
      resources:
        limits:
          memory: 2g
          cpus: "1.5"

Docker Compose v2 ஆனது சாதாரண docker compose up-ல் deploy.resources.limits-ஐப் பயன்படுத்துகிறது, எனவே இதில் swarm mode சம்பந்தப்படவில்லை. பழைய mem_limit: 2g key இப்போதும் வேலை செய்யும். Compose memory limits குறித்த முழுமையான வழிகாட்டி என்பது, ஒதுக்கீடுகள் (reservations) மற்றும் ஒரு container அதன் உச்ச வரம்பை அடையும்போது என்ன நடக்கும் என்பதை விளக்குகிறது. Docker இன்னும் server-ல் இல்லை என்றால், முதலில் VPS-ல் Docker-ஐ நிறுவவும்.

ஒரு பொதுவான தவறு பலரது நேரத்தை வீணாக்குகிறது. 2 GB என வரம்பு நிர்ணயிக்கப்பட்ட ஒரு container, host-ன் /proc/meminfo மற்றும் host-ன் CPU எண்ணிக்கையைத்தான் இன்னும் வாசிக்கும், ஏனெனில் இவை இரண்டும் namespaced செய்யப்படவில்லை. CPU எண்ணிக்கையை வைத்து worker-களின் எண்ணிக்கையைத் தீர்மானிக்கும் ஒரு test runner, 8 vCPU கொண்ட host-ல் 2 GB container-க்குள் 8 worker-களைத் தொடங்கி, பின் 137 என்ற error code-உடன் செயலிழந்துவிடும். எனவே, அந்த எண்களை நீங்களே கைமுறையாக அமைக்கவும்:

npx jest --maxWorkers=2
export NODE_OPTIONS=--max-old-space-size=1536

--max-old-space-size என்பது MB-ல் குறிப்பிடப்பட வேண்டும் மற்றும் இது V8 heap-ஐக் கட்டுப்படுத்தும். இதை container வரம்பை விடக் குறைவாக அமைக்கவும். அப்போதுதான் Node, திடீரென மறைந்துவிடாமல், உங்களால் வாசிக்கக்கூடிய ஒரு error-ஐக் கொடுக்கும்:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

அந்தச் செய்தி ஒரு வரப்பிரசாதம், ஏனெனில் அது எந்த வரம்பு மீறப்பட்டது மற்றும் எந்த process-ஆல் மீறப்பட்டது என்பதைத் தெளிவாகக் குறிப்பிடுகிறது. OOM killer ஒருபோதும் இதைச் செய்வதில்லை.

ஒரே கணினியில் பல agent அமர்வுகளை இயக்குதல்

ஒவ்வொரு நபருக்கும் அல்ல, ஒவ்வொரு அமர்வுக்கும் திட்டமிடுங்கள். ஒரே repository-ல் இரண்டு அமர்வுகள் இயங்கினால், இரண்டு language server-கள், நினைவகத்தில் இரண்டு build cache தொகுப்புகள் மற்றும் இரண்டு agent-களும் ஒரே நேரத்தில் வேலை செய்யத் தொடங்கினால் இரண்டு test run-கள் ஏற்படும். இதனால்தான் team row ஆனது 16 GB அளவுக்கு உயர்கிறது.

ஒவ்வொரு பயனருக்கும் ஒரு கடினமான வரம்பை (hard ceiling) நிர்ணயிப்பதன் மூலம், ஒரு கட்டுப்பாடற்ற அமர்வு முழு கணினியையும் முடக்காமல் தடுக்கலாம்:

id -u alice
sudo mkdir -p /etc/systemd/system/user-1001.slice.d
printf '[Slice]\nMemoryMax=6G\n' | sudo tee /etc/systemd/system/user-1001.slice.d/limit.conf
sudo systemctl daemon-reload
systemctl show user-1001.slice -p MemoryMax

1001 என்பதற்குப் பதிலாக id -u வெளியிட்ட UID-ஐ மாற்றவும். பயனர் உள்நுழைந்த பிறகு systemctl show ஆனது MemoryMax=6442450944 என்பதை echo செய்ய வேண்டும். அந்தப் பயனரின் அமர்வில் உள்ள அனைத்தும் 6 GB-ஐத் தாண்டும்போது, kernel அந்த slice-ல் உள்ள ஒரு process-ஐ நிறுத்திவிடும், மற்ற அனைத்து அமர்வுகளும் தொடர்ந்து இயங்கும். Terminal-ல் இயங்காமல் service-ஆக இயங்கும் agent-க்கு, அதற்குப் பதிலாக அதன் unit file-ல் MemoryMax= என்பதைச் சேர்க்கவும். இதுவே நீங்கள் agent-ஐ எப்போதும் இயங்கும் service-ஆக self-host செய்யும்போது பின்பற்ற வேண்டிய முறையாகும்.

FAQ

2 GB RAM ஒரு coding agent-க்கு போதுமானதா?

Agent process-க்கு இது போதுமானது. ஆனால் அது செய்யும் வேலைகளுக்கு இது அரிதாகவே போதுமானதாக இருக்கும். Agent பொதுவாக 250 MB RAM-ஐப் பயன்படுத்தும். ஆனால், ஒரு நடுத்தர அளவிலான repository-ல் ஒரு TypeScript language server மட்டும் 2000 MB வரை செல்லக்கூடும். இதுவே 2 GB கொண்ட server-ஐ swap-க்குத் தள்ளிவிடும். Config files மற்றும் சிறிய scripts-ஐத் திருத்துவதற்கு 2 GB போதுமானது. எதையாவது compile செய்யவோ அல்லது test suite-ஐ இயக்கவோ திட்டமிட்டால், குறைந்தபட்சம் 4 GB RAM கொண்ட server-ஐப் பயன்படுத்தவும்.

VPS-ல் coding agent-ஐ இயக்க GPU தேவையா?

Agent ஒரு cloud model-ஐ API மூலம் அழைத்தால், GPU தேவையில்லை. அந்த பணி network-ஐச் சார்ந்தது, எனவே சாதாரண CPU VPS-ஏ போதுமானது; GPU-வை அதிக விலைக்கு வாங்கி சும்மா வைத்திருப்பது பயனற்றது. Model-ஐ அதே server-ல் இயக்கினால் மட்டுமே GPU தேவைப்படும்; அப்போது RAM-ஐ விட VRAM மற்றும் model-ன் அளவு முக்கியமானது.

Agent VPS-ல் எவ்வளவு swap சேர்க்க வேண்டும்?

RAM-ன் அளவில் பாதியளவு, அதிகபட்சம் 4 GB வரை சேர்க்கலாம். திடீரென memory தேவை அதிகரிக்கும்போது, kernel process-ஐக் கொல்வதற்குப் பதிலாக, பயன்பாட்டில் இல்லாத தரவுகளை disk-க்கு மாற்றுவதன் மூலம் swap பாதுகாக்கிறது. இது கூடுதல் memory-ஐத் தராது. vmstat 1 கட்டளையில் si மற்றும் so columns-ல் தொடர்ந்து traffic இருந்தால், server-ன் செயல்திறன் குறைகிறது (thrashing) என்று அர்த்தம். அப்போது parallel workers-ன் எண்ணிக்கையைக் குறைப்பது அல்லது அதிக RAM கொண்ட plan-க்கு மாறுவதுதான் தீர்வு.

Build செய்யும்போது ஏன் coding agent freeze ஆகிறது?

Build செயல்முறை பெரும்பாலும் kernel OOM killer-ஆல் நிறுத்தப்பட்டிருக்கலாம். இது SIGKILL-ஐ அனுப்புவதால், எந்தப் பதிவும் (log) வராது; agent நிரப்பப்படாத pipe-க்காகக் காத்திருக்கும். sudo dmesg -T | grep -i "killed process" கட்டளையை இயக்கி, process பெயர் மற்றும் அதன் anon-rss மதிப்பைப் பார்க்கவும். systemd-run --user --scope -p MemoryMax=4G மூலம் build-ன் பயன்பாட்டைக் கட்டுப்படுத்துவது, worker எண்ணிக்கையைக் குறைப்பது அல்லது அதிக RAM கொண்ட server-க்கு மாறுவது மூலம் இதைச் சரிசெய்யலாம்.