Difference between revisions of "Category:Web Server"

* Perhatikan yg diberi angka merah

[1] 9.31 requests/sec vs 3 request currently processed

     Kondisi ini artinya normal, dimana average 9.3 req/sec, dan saat dicapture sedang memproses 3 request.
     Jika ada x req/sec dan y req currently processed, dimana y jauh lebih besar daripada x, maka sudah harus waspada,
     memory leak dan/atau apache child processes hung up sudah mulai menumpuk.

[2] Perhatikan yg diberi tanda "W", jika kondisi y jauh lebih besar > x, biasanya akan menumpuk banyak "W".

     Jika halaman ini kita refresh (F5), server yg normal maka "W" akan berganti2 menjadi _/./dll
     Jika ada banyak W yg selalu tetap W meski direfresh berkali maka sudah hampir pasti itu adalah slot child process
     yg bermasalah.

[3] Perhatikan kolom PID dan Request (ujung kanan).

     Korelasi dengan no [2] diatas, pada saat direfresh (F5) berkali2, dan isi dari kolom Request masih sama terus,
     artinya itulah 1 slot process yg bisa kita investigate lebih lanjut.
     Catat/copy paste PID-nya, ini berguna untuk keperluan trace di server.

Didalam console ssh server bersangkutan, lakukan:

prompt> strace -p pid

httpd process yg normal suatu saat akan terminated/closed,atau kalau process sering dipakai/connected, terlihat akan tampil banyak process2 kernel threads yg berbeda2, artinya dia sedang melayani banyak request dari client.

sedangkan httpd process yg tidak normal, akan terlihat locked dalam infinite loop,dengan beberapa verbose message. biasanya ada melibatkan gettimeofday dan syscall2 lainnya.

nah, khusus untuk kasus ini, akan terlihat syscall futex diulang berkali2, dan most likely menjadi penyebab child process ini tidak bisa dikill/terminated oleh parent process.

hasil observasi beberapa hari terakhir, futex_wait menunggu suatu value tertentu agar bisa closed. reason lebih dalam utk hal ini rasanya tidak perlu dicari lagi, cukup kita ketahui bahwa ada masalah futex oleh apache child process.

2. Penyebab

- Dari sisi os, hal ini terjadi di cross platform, ubuntu, centos, dll, jadi bukan faktor os.

- Dari sisi apache, hal ini terjadi di berbagai versi apache.

- Dari sisi mod2 dalam apache, hasil riset dan tracing di tiap server, beberapa mod yg
  diduga mentrigger deadlock ini antara lain: mod_perl dan mod_pagespeed

Apache, futex, dan mod2 lainnya bukanlah suatu kombinasi buruk. Root problemnya sebenarnya adalah, web app tersebut, dengan catatan penting, ada command2 pada web app yg most likely bisa memancing deadlock terjadi. Command2 ini sebenarnya legitimate, seperti sleep(x), dan lain2, yg memanfaatkan infinite loop algoritma, dan sleep for x nanosecs utk repeat. Jadi kita tidak bisa pointing finger bahwa A yg salah, B benar, C salah, dll. Bug ini terjadi kebetulan dengan komponen2 tersebut diatas.

Jadi kita dihadapkan pada pilihan sulit, tidak mungkin meminta user stop memakai beberapa syscall pada php, karena itu legit. Merombak futex pun tidak mungkin, meski beberapa engineer di luar sana sudah mulai mengoprek2.

3. Solusi

Tidak mungkin mematikan mod_perl, sebab ini juga sering dianggap "standard" instalasi.
Tidak mungkin mendisable syscall2 default bawaan php.
Satu2nya cara dengan mendisable mod_pagespeed, yg juga heavy dalam interlocking linux threads.

4. Konsekuensi

Tidak ada lagi peran backend cache dalam minifikasi html resources, setidaknya masih ada eaccelerator utk php script cache.
Catatan: eaccelerator jg menggunakan locking yaitu spinlock, tapi aman dari kondisi bug ini.

5. Possible workaround.

Harus menunggu release berikut dari pagespeed, apache, php, dll agar tidak lagi deadlock.

6. Implementasi

Kemarin malam, semua web server LCTeCo dan LC_Tribun sudah saya disable pagespeednya. Silakan lanjut pada cluster lainnya, seperti LC_Daerah dll.

7. Relasi terhadap setting httpd.conf

Beberapa hari lalu sempat saya request perubahan setting MaxRequestPerChild.
Angka ini menandakan upper limit bagi suati spawned httpd process utk keep process request.
Setelah melewati angka ini maka child process tersebut harus diterminasi.
Nah, jika angka ini terlalu besar, dan berbenturan dengan bug ini, yg terjadi server akan sangat berat.

Untuk kondisi normal, angka yg terlalu kecil akan menaikkan load cpu, sebab destroy/create child process akan butuh cpu load. Semakin lama child dikeep alive, semakin sedikit overhead di cpu. Tapi jika child terlalu lama dikeep, sangat prone to memory leak, dan possibly memancing bug seperti kasus ini. Analoginya, semakin cepat/sering dikill, agar tidak terlanjur memancing bug spawned pada child tersebut. Tapi semakin sering sibuk kill/create process, cpu makin tinggi load dipake utk manage hal2 internal seperti ini, instead dipake utk process request dari client browser.