Nginx

Worker Processes และ Connections Optimization ใน Nginx

Categories

Nginx เป็น web server ที่โด่งดังในการจัดการเว็บไซต์ขนาดใหญ่และมีอัตราการเข้าถึงสูง หนึ่งในเหตุผลที่ Nginx มีประสิทธิภาพสูงคือการใช้สถาปัตยกรรม event-driven ที่มีการกำหนด Worker Processes และ Worker Connections อย่างเหมาะสม การปรับแต่งค่าเหล่านี้ได้อย่างถูกต้องจะช่วยเพิ่มความเร็วของเว็บไซต์ ลดการใช้หน่วยความจำ และรองรับผู้ใช้งานจำนวนมากขึ้น

บทความนี้จะอธิบายวิธีการปรับแต่ง Worker Processes และ Connections ใน Nginx ให้เหมาะสมกับโครงสร้างระบบของคุณ โดยครอบคลุมตั้งแต่แนวคิดพื้นฐานจนถึงกลยุทธ์การปรับแต่งขั้นสูง

Worker Processes คืออะไร

Worker Process คือกระบวนการหลักของ Nginx ที่จัดการคำขอ HTTP จากไคลเอนต์ แต่ละ worker process สามารถจัดการหลายการเชื่อมต่อพร้อมกันได้ (asynchronous) ผ่านการใช้ event loop mechanism เช่น epoll (Linux) หรือ kqueue (BSD)

ต่างจาก Apache ที่มีแนวทาง process-based (สร้าง process หรือ thread ใหม่สำหรับแต่ละการเชื่อมต่อ) Nginx ใช้แนวทาง event-based ที่ประหยัดทรัพยากรมากขึ้น

การกำหนด Worker Processes

1. Auto (ค่าอัตโนมัติ)

ในไฟล์ nginx.conf คุณสามารถตั้งค่า worker processes เป็น auto เพื่อให้ Nginx จำนวน worker processes โดยอัตโนมัติตามจำนวน CPU cores ที่มีอยู่:

worker_processes auto;

วิธีนี้เหมาะสำหรับเซิร์ฟเวอร์ส่วนใหญ่ เพราะ Nginx จะปรับให้เข้ากับจำนวน CPU cores โดยอัตโนมัติ

2. Manual (กำหนดด้วยตนเอง)

หากคุณต้องการควบคุมจำนวน worker processes โดยชัดเจน สามารถระบุเป็นตัวเลขได้:

worker_processes 4;

ค่าที่เหมาะสมคือ:

  • สำหรับเซิร์ฟเวอร์ 4 cores: worker_processes 4;
  • สำหรับเซิร์ฟเวอร์ 8 cores: worker_processes 8;
  • สำหรับเซิร์ฟเวอร์ 16 cores: worker_processes 16;

เคล็ดลับ: หากต้องการรู้จำนวน CPU cores ของระบบ ใช้คำสั่ง:

nproc
# หรือ
grep -c ^processor /proc/cpuinfo

Worker Connections — จำนวนการเชื่อมต่อต่อ Worker

Worker Connections (worker_connections) คือจำนวนสูงสุดของการเชื่อมต่อพร้อมกัน (concurrent connections) ที่ worker process หนึ่งตัวสามารถจัดการได้

events {
    worker_connections 1024;
}

ค่าเริ่มต้นของ Nginx คือ 512 ซึ่งเพียงพอสำหรับเซิร์ฟเวอร์ขนาดเล็ก แต่สำหรับเซิร์ฟเวอร์ที่มีปริมาณ traffic สูง ควรเพิ่มค่านี้เป็น 2048 หรือ 4096

การคำนวณ Worker Connections ที่เหมาะสม

สูตรการคำนวณจำนวนการเชื่อมต่อทั้งหมดที่เซิร์ฟเวอร์สามารถรองรับได้:

max_connections = worker_processes × worker_connections

ตัวอย่าง:

  • worker_processes = 4
  • worker_connections = 2048
  • max_connections = 4 × 2048 = 8192 connections

Worker RLIMIT NOFILE — จำนวนไฟล์ที่เปิดได้

ระบบปฏิบัติการ Linux มีข้อจำกัดในจำนวนไฟล์ (file descriptors) ที่กระบวนการหนึ่งสามารถเปิดได้พร้อมกัน ซึ่งเรียกว่า NOFILE limit (number of open files limit)

หากคุณตั้ง worker_connections สูง แต่ NOFILE limit ต่ำ Nginx อาจไม่สามารถรองรับการเชื่อมต่อทั้งหมดได้

events {
    worker_connections 10000;
    worker_rlimit_nofile 65535;
}

ตรวจสอบค่าปัจจุบันด้วยคำสั่ง:

ulimit -n
# หากต้องการเปลี่ยน limit ชั่วคราว
ulimit -n 65535

สำหรับการตั้งค่าถาวร ให้แก้ไข /etc/security/limits.conf:

nginx soft nofile 65535
nginx hard nofile 65535

Multi Accept — การยอมรับการเชื่อมต่อหลายรายการ

Multi Accept คือคุณสมบัติที่ช่วยให้ worker process สามารถยอมรับการเชื่อมต่อใหม่หลายรายการในหนึ่งครั้ง แทนที่จะยอมรับแบบหนึ่งต่อหนึ่ง

events {
    multi_accept on;
}

การเปิด multi_accept สามารถช่วยลดเวลาในการยอมรับการเชื่อมต่อใหม่ และเพิ่มอัตราการประมวลผล โดยเฉพาะอย่างยิ่งเมื่อมี traffic spike

การเลือก Event Method — epoll vs kqueue

Nginx ใช้ event method ที่แตกต่างกันไปตามระบบปฏิบัติการ:

  • epoll — Linux (รุ่น 2.6 ขึ้นไป) — ประสิทธิภาพสูงสุด
  • kqueue — BSD/macOS — ประสิทธิภาพสูง
  • select — Windows, เก่า — ประสิทธิภาพต่ำ
  • poll — Fallback ทั่วไป

ตรวจสอบว่า Nginx ของคุณใช้ event method ใด:

nginx -V 2>&1 | grep -i event
events {
    use epoll;
    worker_connections 10000;
}

Events Block Optimization — การปรับแต่ง Events Block

ตัวอย่างการปรับแต่ง Events Block ที่สมดุลระหว่างประสิทธิภาพและเสถียรภาพ:

events {
    # จำนวน worker processes
    worker_processes auto;

    # ใช้ epoll เพื่อประสิทธิภาพสูง (Linux)
    use epoll;

    # จำนวนการเชื่อมต่อต่อ worker
    worker_connections 4096;

    # ยอมรับการเชื่อมต่อหลายรายการ
    multi_accept on;
}

Worker CPU Affinity — เชื่อมต่อ Worker กับ CPU Cores

Worker CPU Affinity (worker_cpu_affinity) คือการเชื่อมต่อ worker process กับ CPU core เฉพาะเพื่อลดการเปลี่ยน context และเพิ่มประสิทธิภาพ cache

# สำหรับเซิร์ฟเวอร์ 4 cores
worker_cpu_affinity 01 10 100 1000;

# หรือ
worker_cpu_affinity 0001 0010 0100 1000;

สตริง binary ที่ใช้ในตำแหน่งที่ตรงกับ worker process นั้น ๆ เช่น:

  • Worker 1: 01 = CPU core 0
  • Worker 2: 10 = CPU core 1
  • Worker 3: 100 = CPU core 2
  • Worker 4: 1000 = CPU core 3

หรือใช้ auto เพื่อให้ Nginx จัดสรร worker ให้ CPU cores โดยอัตโนมัติ:

worker_cpu_affinity auto;

Worker Priority — ระดับความสำคัญของ Worker Process

Worker Priority (worker_priority) ใช้ในการกำหนด nice value ของ worker process ซึ่งมีค่าตั้งแต่ -20 (ความสำคัญสูง) ถึง 19 (ความสำคัญต่ำ)

# ให้ worker priority สูงกว่าปกติ
worker_priority -5;

ค่าติดลบหมายถึง priority สูง ค่าบวกหมายถึง priority ต่ำ การกำหนด worker_priority ให้ติดลบจะช่วยให้ Nginx ได้รับการประมวลผลคำขอด้วยความสำคัญที่สูงกว่า

Accept Mutex — การล็อคการยอมรับการเชื่อมต่อ

Accept Mutex (accept_mutex) ใช้ในการป้องกัน “thundering herd” problem ซึ่งเกิดขึ้นเมื่อ worker processes หลายตัวพยายามยอมรับการเชื่อมต่อเดียวกันพร้อมกัน

events {
    accept_mutex on;
    accept_mutex_delay 500ms;
}

ค่าเริ่มต้นคือ on ซึ่งเหมาะสำหรับเซิร์ฟเวอร์ส่วนใหญ่ เมื่อเปิด accept_mutex worker processes จะล็อคไว้และยอมรับการเชื่อมต่อตามลำดับ ลดภาระของระบบปฏิบัติการ

การติดตามประสิทธิภาพ Worker — Monitoring Worker Performance

ก่อนและหลังการปรับแต่ง ควรติดตามประสิทธิภาพของ worker processes เพื่อให้แน่ใจว่าการปรับแต่งทำให้ระบบดีขึ้น

1. ตรวจสอบจำนวน Worker Processes

ps aux | grep "nginx: worker"
# หรือ
pgrep -f "nginx: worker" | wc -l

2. ตรวจสอบการใช้หน่วยความจำและ CPU

ps aux | grep nginx
# หรือ
top -p $(pgrep -d, nginx)

3. ติดตามการเชื่อมต่อ

netstat -tna | grep ESTABLISHED | wc -l
# หรือ
ss -tna | grep ESTABLISHED | wc -l

4. ตรวจสอบ Nginx Stub Status

หาก Nginx ของคุณเปิดใช้งาน stub_status module คุณสามารถดูสถิติการเชื่อมต่อแบบเรียลไทม์:

curl localhost/nginx_status

output จะแสดง:

Active connections: 42
server accepts handled requests
    1234 1234 5678
Reading: 0 Writing: 5 Waiting: 37

กลยุทธ์การปรับแต่ง — Scaling Strategies

1. สำหรับเซิร์ฟเวอร์ขนาดเล็ก (Low Traffic)

user nginx;
worker_processes auto;

events {
    use epoll;
    worker_connections 1024;
    multi_accept off;
}

2. สำหรับเซิร์ฟเวอร์ขนาดกลาง (Medium Traffic)

user nginx;
worker_processes auto;
worker_rlimit_nofile 65535;

events {
    use epoll;
    worker_connections 4096;
    multi_accept on;
    accept_mutex on;
}

3. สำหรับเซิร์ฟเวอร์ขนาดใหญ่ (High Traffic)

user nginx;
worker_processes auto;
worker_rlimit_nofile 65535;
worker_cpu_affinity auto;

events {
    use epoll;
    worker_connections 10000;
    multi_accept on;
    accept_mutex off;
}

ตัวอย่างการปรับแต่งจริง — Real-world Tuning Examples

ตัวอย่าง 1: เซิร์ฟเวอร์ 4 cores ที่มี traffic 5000 connections/sec

user nginx;
worker_processes 4;
worker_rlimit_nofile 100000;
worker_priority -10;

events {
    use epoll;
    worker_connections 8000;
    multi_accept on;
    accept_mutex off;
}

http {
    # ... HTTP configuration
}

คำอธิบาย:

  • 4 workers × 8000 connections = 32,000 max concurrent connections
  • worker_rlimit_nofile 100000 เพื่อรองรับ file descriptors มากขึ้น
  • worker_priority -10 เพื่อให้ Nginx มี priority สูง
  • accept_mutex off เพราะ Nginx version 1.11.3+ ข้อแนะนำให้ปิดเพื่อประสิทธิภาพที่ดีขึ้น

ตัวอย่าง 2: เซิร์ฟเวอร์ 8 cores ที่เรียกใช้ WordPress

user nginx;
worker_processes auto;
worker_rlimit_nofile 50000;
worker_cpu_affinity auto;

events {
    use epoll;
    worker_connections 4096;
    multi_accept on;
    accept_mutex on;
    accept_mutex_delay 200ms;
}

http {
    keepalive_timeout 65;

    # ... HTTP configuration
}

คำอธิบาย:

  • worker_processes auto จะใช้ 8 workers (8 cores)
  • 8 workers × 4096 connections = 32,768 max connections
  • worker_cpu_affinity auto เพื่อให้แต่ละ worker เชื่อมต่อกับ CPU core
  • accept_mutex on เพื่อลดการแย่งชิง connection

วิธีปฏิบัติที่ดีที่สุด — Best Practices

  • เริ่มต้นด้วยค่า auto: ให้ Nginx เลือก worker_processes โดยอัตโนมัติตามจำนวน CPU cores
  • ตรวจสอบปัจจุบันของระบบ: ดู ulimit -n และ cat /proc/sys/net/core/somaxconn เพื่อให้แน่ใจว่ามีพอ file descriptors
  • ปรับแต่งแบบค่อยเป็นค่อยไป: เปลี่ยนแปลงค่าหนึ่งค่าในครั้งหนึ่ง และติดตามผลในแต่ละครั้ง
  • ใช้ monitoring tools: ใช้เครื่องมือเช่น Prometheus, Grafana หรือ New Relic เพื่อติดตามประสิทธิภาพ
  • ทดสอบด้วย load testing: ใช้เครื่องมือเช่น Apache JMeter, wrk หรือ Locust เพื่อจำลอง traffic ที่หนัก
  • เปิดใช้ epoll/kqueue: ตรวจสอบให้แน่ใจว่า Nginx ใช้ event method ที่สำหรับระบบปฏิบัติการของคุณ
  • ตั้ง worker_rlimit_nofile เพียงพอ: กำหนดค่าให้สูงกว่า worker_connections × worker_processes อย่างน้อย 2 เท่า
  • ทำให้เรียบง่าย: อย่าตั้งค่าที่ซับซ้อนเกินไป เนื่องจากอาจทำให้เกิดปัญหาที่คาดไม่ถึง

สรุป

การปรับแต่ง Worker Processes และ Connections ใน Nginx เป็นกุญแจสำคัญในการเพิ่มประสิทธิภาพเซิร์ฟเวอร์ ผ่านการตั้งค่า worker_processes, worker_connections, worker_rlimit_nofile และอื่น ๆ อย่างถูกต้อง คุณสามารถทำให้ Nginx จัดการ traffic ที่หนักได้อย่างมีประสิทธิภาพ

สิ่งที่สำคัญที่สุดคือการทำให้เข้าใจ bottleneck ของระบบของคุณ โดยการติดตามและทดสอบอย่างต่อเนื่อง พร้อมทั้งปรับแต่งตามความต้องการเฉพาะของแต่ละสถานการณ์

แนะนำบริการ DE Cloud VPS/Cloud Hosting

การปรับแต่ง Nginx อย่างละเอียดนี้จำเป็นต้องมี VPS หรือ Dedicated Server ที่ให้คุณเต็มสิทธิในการแก้ไข nginx.conf โดยตรง

DE Cloud VPS ให้คุณควบคุมเซิร์ฟเวอร์ได้เต็มที่ด้วยความเป็นส่วนตัว (private) และสามารถปรับแต่ง Nginx ตามความต้องการได้โดยไม่มีข้อจำกัด รวมถึงการสนับสนุนระบบปฏิบัติการเวอร์ชันใหม่ที่มี epoll ที่ปรับปรุงแล้ว

สำหรับเว็บไซต์ WordPress ที่ต้องการ Nginx optimization แบบเต็มที่ DE Cloud Hosting ก็เป็นตัวเลือกที่ดี โดยทีมผู้เชี่ยวชาญของ DE สามารถช่วยปรับแต่ง Nginx configuration สำหรับไซต์ WordPress ของคุณได้

ดูบริการ Cloud VPS ของ DE หรือ ดูบริการ Cloud Hosting ของ DE เพื่อทราบข้อมูลเพิ่มเติม