hi anh quanta, 2 value đó em đã thử set lên rồi nhưng tình hình vẫn không khá hơn ,
 

#define TCP_TIMEWAIT_LEN (60*HZ)

#define TCP_TIMEWAIT_LEN (15*HZ)

sau đó em đã thử tiếp giảm value của tcp_fin_timeout (từ 15 xuống 1), tuy nhiên tình hình vẫn như vậy. 

secmask wrote:

hi anh quanta, 2 value đó em đã thử set lên rồi nhưng tình hình vẫn không khá hơn ,
 

Lạ nhỉ! Vậy thử thêm vài cách nữa:
- giảm cái ip_local_port_range xuống 1024 65000 xem sao
- Biên dịch lại kernel, trong file /usr/src/linux/include/net/tcp.h sửa dòng này:
Code:

#define TCP_TIMEWAIT_LEN (60*HZ)

thành:
Code:

#define TCP_TIMEWAIT_LEN (15*HZ)

chẳng hạn.

secmask wrote:

sau đó em đã thử tiếp giảm value của tcp_fin_timeout (từ 15 xuống 1), tuy nhiên tình hình vẫn như vậy. 

Cái FIN_TIMEOUT nó không liên quan đến TIME_WAIT length thì phải.
 

TIME_WAIT là trạng thái cuối cùng của một kết nối tcp trước khi đóng kết nối chủ động (chủ động gửi FIN). Hiện tượng nhiều TIME_WAIT thực ra không phải lỗi của OS hay TCP/IP stack mà nguyên nhân thường bắt nguồn từ tốc độ mở socket mới quá nhanh so với tốc độ giải phóng socket: mỗi socket sẽ đợi ở tình trạng TIME_WAIT 1 khoảng thời gian là 2 *MSL (thông thường là 120s, trên CentOS là 60s).
 

Để khắc phục vấn đề này có các hướng sau:
- Điều chỉnh tcp/ip stack nhằm giảm thời gian time_out để đóng socket time_wait và tái sử dụng socket: như quanta và secmask đang làm.

- Xem xét ở tầng app xem tại sao client sinh ra nhiều socket tới server tới vậy (thường là do lỗi lập trình). Ở đây là kết nối http, thử xem xét vấn đề về keep-alive để tiết kiệm số sockets xem sao.

- Search google: có một số giải pháp ở tầng TCP hoặc HTTP cho phép chủ động đóng bớt TIME_WAIT (Client chủ động gửi RST; thêm method CLOSE ở giao thức HTTP), nhưng có vẻ là khó triển khai với trường hợp này.
 

hix, tình hình là em mới thử qua mấy kịch bản test như sau:
giả sử đặt tên lighttpd trên server 89 là lighttpd89, memcacheq trên server 89 là memcacheq89 và php-cgi là php-cgi89, 2 server còn lại đặt tên tương tự.

Test1: lighttpd89 --> php-cgi89 --> memcacheq89 --> TIME_WAIT rất nhiều
Test2: lighttpd102 --> php-cgi102 --> memcacheq102 --> TIME_WAIT ít (tình trạng bình thường)
Test3: lighttpd89 --> php-cgi102 --> memcacheq102 --> trường hợp này em đặt lighttpd trên 89 gọi php-cgi nằm trên sever 102 qua tcp/ip (php-cgi và memcacheq trên 102 vẫn dùng hàng ngày và chạy tốt), lúc này server 102 có TIME_WAIT rất nhiều từ php-cgi sang memcacheq ==> có thể là tại lighttpd.
Test4: không dùng lighttpd nữa, em chuyển sang dùng nginx, kết quả là nginx cũng gặp tình trạng như với lighttpd
Đến đây thì em bó tay, không đoán được là tại thằng nào nữa . Liệu còn nguyên nhân gì không các bác nhỉ? 

....
code php ở đây chỉ làm công việc là kết nối đến memcacheq server và set một giá trị vào memcacheq.
....

....
code php kết nối đến memcacheq local của riêng mình.
....

 

secmask wrote:

....
code php ở đây chỉ làm công việc là kết nối đến memcacheq server và set một giá trị vào memcacheq.
....

....
code php kết nối đến memcacheq local của riêng mình.
....

 

1. Kết nối local giữa php tới memcached tại sao không xài Unix domain socket mà xài TCP socket chi vậy ? Unix domain socket không phải chịu các overhead của TCP socket như encap, decap, checksum calculate, verify, flow control,... Tui coi PHP manual của memcache_connect thì thấy nó cũng support Unix domain socket.

2. Nếu ông vẫn quá khoái xài AF_INET socket, mà mỗi lần kết nối từ php-cgi vào memcacheq chỉ để set 1 giá trị, tại sao không thử xài UDP thay vì TCP ? Thay vì tốn nhiều memory cho TCP socket creation/destruction, memory đó được memcache tận dụng thì vẫn hơn. 

echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
echo 1 > /proc/sys/net/ipv4/tcp_timestamps

server.max-keep-alive-requests = 0
server.max-keep-alive-idle = 5
server.max-fds = 16384
server.max-connections = 8192
 

server.max-keep-alive-requests = 4
server.max-keep-alive-idle = 5
server.max-fds = 16384
server.max-connections = 8192
 

ok, nghe cũng ná ná trường hơp của tớ , bạn thử áp dụng cách của tớ chưa? kết quả sao, cái này chỉ cần chỉnh mấy thông số trong kernel thôi, không cần dịch lại kernel. nếu thấy ổn thì có thể add config đó vào /etc/sysctl.conf để có hiệu lực lâu dài. 

secmask wrote:

ok, nghe cũng ná ná trường hơp của tớ , bạn thử áp dụng cách của tớ chưa? kết quả sao, cái này chỉ cần chỉnh mấy thông số trong kernel thôi, không cần dịch lại kernel. nếu thấy ổn thì có thể add config đó vào /etc/sysctl.conf để có hiệu lực lâu dài. 

Chào bác

Nguyên nhân căn bản vẫn là do có quá nhiều TIME_WAIT giống như bác, nếu ngắt đi được cái TIME_WAIT thì tốt,

nhưng em đang chạy VPS chứ không phải server riêng, quyền root có thể ghi vào fule sysctl.conf nhưng các lệnh trong đó thì không có quyền thực hiện. Em không được sửa kernel vì HP họ nó sửa là ảnh hưởng tới các VPS khác trên cùng server;

Hiện giờ em chỉ cố gắng tune cho nó chạy tạm hết cỡ cho tròn tháng này để em chuyển sang dedicated server... nếu bác có tìm ra đựoc cái gì để tune tạm trong thời gian này thì chỉ em với nhé... thanks bác hehe! 

namduong8889 wrote:

secmask wrote:

ok, nghe cũng ná ná trường hơp của tớ , bạn thử áp dụng cách của tớ chưa? kết quả sao, cái này chỉ cần chỉnh mấy thông số trong kernel thôi, không cần dịch lại kernel. nếu thấy ổn thì có thể add config đó vào /etc/sysctl.conf để có hiệu lực lâu dài. 

Chào bác

Nguyên nhân căn bản vẫn là do có quá nhiều TIME_WAIT giống như bác, nếu ngắt đi được cái TIME_WAIT thì tốt,

nhưng em đang chạy VPS chứ không phải server riêng, quyền root có thể ghi vào fule sysctl.conf nhưng các lệnh trong đó thì không có quyền thực hiện. Em không được sửa kernel vì HP họ nó sửa là ảnh hưởng tới các VPS khác trên cùng server;

Hiện giờ em chỉ cố gắng tune cho nó chạy tạm hết cỡ cho tròn tháng này để em chuyển sang dedicated server... nếu bác có tìm ra đựoc cái gì để tune tạm trong thời gian này thì chỉ em với nhé... thanks bác hehe! 

VPS = Virtual Private Server , tức là server của bạn được cài trên máy ảo, cùng với các server ảo khác trên một máy vật lý, vì vậy cấu hình các server ảo nào không hề phụ thuộc vào nhau, làm gì có chuyện ảnh hưởng tới các máy ảo khác được, bạn nên hỏi lại bên cho thuê server. Khi bạn đã thuê một vps, bạn đươc toàn quyền cài đặt từ OS đến các phần mềm trên đó. 

Chào bạn,

Do giá trị /proc/sys/net/ipv4/tcp_fin_timeout ảnh hưởng toàn bộ các VPS trên cùng hệ thống nên VinaHost chỉ có thể giảm xuống 30. Nếu hiện tượng bị ngắt vẫn còn tiếp diễn thì bạn nên thử chạy Apache + mod_php thay vì lighttpd một vài ngày xem có khác biệt không. Cơ chế quản lý, tạo PHP process của lighttpd cũng không thực sự tốt lắm và cũng có thể là 1 nguyên nhân gây ra lỗi trên.

Thân, 

TIME_WAIT là trạng thái cuối cùng của một kết nối tcp trước khi đóng kết nối chủ động (chủ động gửi FIN). Hiện tượng nhiều TIME_WAIT thực ra không phải lỗi của OS hay TCP/IP stack mà nguyên nhân thường bắt nguồn từ tốc độ mở socket mới quá nhanh so với tốc độ giải phóng socket: mỗi socket sẽ đợi ở tình trạng TIME_WAIT 1 khoảng thời gian là 2 *MSL (thông thường là 120s, trên CentOS là 60s).

Để khắc phục vấn đề này có các hướng sau:
- Điều chỉnh tcp/ip stack nhằm giảm thời gian time_out để đóng socket time_wait và tái sử dụng socket: như quanta và secmask đang làm.

- Xem xét ở tầng app xem tại sao client sinh ra nhiều socket tới server tới vậy (thường là do lỗi lập trình). Ở đây là kết nối http, thử xem xét vấn đề về keep-alive để tiết kiệm số sockets xem sao.

- Search google: có một số giải pháp ở tầng TCP hoặc HTTP cho phép chủ động đóng bớt TIME_WAIT (Client chủ động gửi RST; thêm method CLOSE ở giao thức HTTP), nhưng có vẻ là khó triển khai với trường hợp này.
 

namduong8889 wrote:

secmask wrote:

ok, nghe cũng ná ná trường hơp của tớ , bạn thử áp dụng cách của tớ chưa? kết quả sao, cái này chỉ cần chỉnh mấy thông số trong kernel thôi, không cần dịch lại kernel. nếu thấy ổn thì có thể add config đó vào /etc/sysctl.conf để có hiệu lực lâu dài. 

Chào bác

Nguyên nhân căn bản vẫn là do có quá nhiều TIME_WAIT giống như bác, nếu ngắt đi được cái TIME_WAIT thì tốt,

nhưng em đang chạy VPS chứ không phải server riêng, quyền root có thể ghi vào fule sysctl.conf nhưng các lệnh trong đó thì không có quyền thực hiện. Em không được sửa kernel vì HP họ nó sửa là ảnh hưởng tới các VPS khác trên cùng server;

Hiện giờ em chỉ cố gắng tune cho nó chạy tạm hết cỡ cho tròn tháng này để em chuyển sang dedicated server... nếu bác có tìm ra đựoc cái gì để tune tạm trong thời gian này thì chỉ em với nhé... thanks bác hehe! 

VPS = Virtual Private Server , tức là server của bạn được cài trên máy ảo, cùng với các server ảo khác trên một máy vật lý, vì vậy cấu hình các server ảo nào không hề phụ thuộc vào nhau, làm gì có chuyện ảnh hưởng tới các máy ảo khác được, bạn nên hỏi lại bên cho thuê server. Khi bạn đã thuê một vps, bạn đươc toàn quyền cài đặt từ OS đến các phần mềm trên đó. 

@crazym: Vấn đề bạn test thử sync flood và TIME_WAIT có vẻ không ăn nhập với nhau lắm.
sync flood thông thường thì bạn chỉ cần enable sync cookie lên là được rồi, TIME_WAIT thì kết nối đã hình thành rồi, không còn liên quan đến sync flood nữa, TIME_WAIT khoảng 1000 như của bạn nhưng nếu ổn định không tăng và hệ thống vẫn chạy thông suốt thì không cần phải lo lắng.