Messages posted by: secmask

LeVuHoang wrote:

Tui có down thử bản Trial của BKAV về chạy test nhưng bắt nhập key khi quét.
False Positive nhiều quá, nhưng dù sao cũng nên khuyến khích. Hy vọng phiên bản sau sẽ quét chính xác hơn.

người ta đang beta mà bác đã chờ phiên bản sau, dìm hàng ác quá smilie

đó là javascript smilie

http://kb.mozillazine.org/Extension_development
bạn có thể xem hướng dẫn đầy đủ về development firefox extension ở đây, firefox có một plugin để support dev là Extension Developer, bạn tìm hiểu thêm nhé smilie

xpi thực chất là một file zip, bạn có thể đổi ext thành .zip rồi extract ra sửa, sau đó zip lại và chuyển thành .xpi

@gamma95: em chạy cả 2 đoạn đó với centos 5.2 perl 5.8.8 đều ra kết quả bình thường smilie

, ko thấy bị "im lặng", còn giá trị có sai lệch 1 chút, có lẽ perl nó dùng floating point hay gì đó , cái này đợi cao nhân perl vào giải thích, em mới đọc xíu để demo cái tính ! thôi smilie

em đọc một tẹo perl và xin đưa ra phương án tương đương trong perl để tính 1000! smilie

, cái chính là việc support bigint (ko rõ từ version nào nữa)
Code:

use bigint;
$x = 2;
for($y=3;$y<=1000;$y++){
$x=$x*$y;
}
print $x;

tớ thử một tẹo với IDM 5.12 thấy vẫn download đc ảnh ở site đó mà smilie

, grabber để level 3, enable java script processing (mấy ảnh cỡ lớn ~500kb ).

gnome chắc nó chơi kiểu này http://www.share-linux.com/hal1.php

dahiphop wrote:

Crackme của chủ topic hỉnh như tui cũng có 1 bản English download ở mạng về từ tuts4you ( chắc vậy ) ... Không biết là tự mình làm hay là... cướp..bản...quyền không nữa !!

trên tuts4you chính là bác deux đây chứ ai smilie

nếu bạn không có quyền control toàn bộ cái server đấy thì tớ cũng bó tay smilie

.
@: ls -l /etc/sysctl.conf thì kết quả thế nào bạn?

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 đó.

ok, nghe cũng ná ná trường hơp của tớ smilie

, 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.

bạn có thể cho xem kết quả của các lệnh sau nhé:
Code:

netstat -nt|grep TIME_WAIT|wc -l

Code:

netstat -nt|grep ESTABLISHED|wc -l

và cấu hình cho lighttpd nữa.

google với mấy từ khóa nhìn thấy được trên màn hình : "firefox int hex mysql mssql" rồi nhảy vào kết quả đầu tiên coi smilie

rcrackvn wrote:

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.

tại vì memcacheq sau đó được một ứng dụng ở máy khác đọc sang nữa, nên tớ không dùng unix-socket được, memcache-client của mình thì không chắc lắm nó có support udp không nên tạm thời vẫn dùng tcp.
May mắn là đến giờ này mình đã tìm được nguyên nhân của căn bệnh, vẫn liên quan đến khả năng recycle các TIME_WAIT socket, tuy nhiên còn một tham số nữa ảnh hưởng đến khả năng recycle là tcp_timestamps. Kernel tái sử dụng các TIME_WAIT socket dựa trên timestamps, thông số này trước đây bị disable nên đã làm cho kernel không thể tái sử dụng được khiến số TIME_WAIT socket tăng cao.
tóm lại, set các thông số sau đã giải quyết được vấn đề TIME_WAIT của mình:
Code:

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

thanks all smilie

chào mfeng!

mfeng wrote:

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).

đây là server dùng để analytics của cty mình nên lượng request đổ về hàng ngày cũng khá lớn (mỗi server khoảng 30 triệu/ngày), các socket được đóng mở thường xuyên.

mfeng wrote:

Để 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.

mình cũng search trên google về lỗi này mấy hôm nay rồi, cũng đã thử chỉnh vài thông số trong /proc/sys/net/ipv4 tuy nhiên vẫn không hiệu quả lắm, và đau đầu nhất là trong 3 server lại chỉ có một server bị tình trang trên.

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 smilie

. Liệu còn nguyên nhân gì không các bác nhỉ?

dạ, em sẽ kiểm tra và thử vài trường hợp nữa, cố gắng khoanh vùng xem vấn đề tại OS hay tại apps.

quanta wrote:

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.

--> cái này thì em có thử đổi range từ 32 000 --> 65 000 thành 10 000 --> 65 000 , tuy nhiên em vẫn chưa tìm ra được lý do mà 3 server được cài đặt tương tự nhau, lại chỉ có một server bị tình trạng "lụt" socket với TIME_WAIT state thế này, 2 server còn lại số socket bị TIME_WAIT chỉ tầm vài chục đến vài trăm.
--->thông số này ở 3 server cũng giống nhau, em cũng tính dịch lại kernel rồi, nhưng đang cố thử tìm nguyên nhân của "căn bệnh" này trước smilie

cám ơn anh, em đang đọc cái link anh gửi xem sao.

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 smilie

,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.

mình bổ sung thêm đoạn thông báo lỗi trong log của lighttpd
Code:

2009-05-19 17:36:52: (mod_fastcgi.c.2618) FastCGI-stderr: PHP Notice: memcache_connect() [<a href='function.memcache-connect'>function.memcache-connect</a>]: Server 192.168.5.89 (tcp 22202) failed with: Cannot assign requested address (99) in /srv/www/lighttpd/_adv.php on line 41

atop hệ thống.

khi bị lỗi lượng RAM cache vẫn khá lớn.

chào các anh em.
Server chỗ mình đang gặp tình trạng lỗi khó hiểu, nhờ mọi người giúp đỡ nha smilie

1.Trình tự
Hiện tại bên mình có 3 webserver (tạm gọi theo ip là 88, 89 và 102) dùng lighttpd, fast php-cgi, centos 5.3 (64 bit) đã được cân bằng tải dùng lvs. Sau khi được cân bằng tải, request được đi vào một trong 3 webserver, tại webserver, lighttpd sẽ nhận request và giao cho php-cgi xử lý, 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.

2.Cấu hình
mỗi web server có cấu hình như sau: chip 4 core, 16Gb Ram, được cài đặt lighttpd (lighttpd quản lý khoảng 1000 process php-cgi), memcacheq. Cả 3 server đều được cấu hình tương tự nhau (về cả hardware và software), code php kết nối đến memcacheq local của riêng mình.

3.Vấn đề
các server này đều phải chịu tải khá cao, trong 3 server trên, server 88 và 102 đều hoạt động bình thường, riêng server 89 thì có số connection trong trạng thái TIME_WAIT rất cao (có thời điểm đạt tới ~30 000), dẫn đến tình trạng thiếu local port cấp phát cho các socket mới (cat /proc/sys/net/ipv4/ip_local_port_range --> 32000 65000), xem netstat thì thấy hầu hết các socket bị TIME_WAIT là các connection từ php-cgi sang memcacheq

sau đây là một số info
Code:

[root@SVR146R-589 ~]# netstat -tnp|wc -l
10277

trong đó có khoảng 7000 trong tình trạng TIME_WAIT của php-cgi sang memcacheq

Code:

[root@SVR145R-588 ~]# netstat -tnp|wc -l
804
netstat -nt|grep TIME_WAIT|wc -l
140

Code:

[root@SVR145L-29102 ~]# netstat -tnp|wc -l
936

nếu cần thông tin gì nữa mình sẽ post lên thêm, hiện tại mình đang tạm thời khắc phục tình trạng quá nhiều socket bị TIME_WAIT này bằng cách set /proc/sys/net/ipv4/tcp_max_tw_buckets = 5000 , các bác cho em xin ý kiến để khắc phục tình trạng trên với nhé.
thanks.

quano1 wrote:

@nbthanh: mình không hiểu ý bạn.
cái code trên mình copy trong ebook tiếng anh hướng dẫn đầy đủ và chi tiết. mình có thể khẳng định cú pháp này không sai chỗ nào
còn cái SQL enterprise 2008. bạn cứ thử vào trang download MySQL của MC xem nó phân ra bao nhiêu cái package của MSQL. có thể mình hiểu sai nhưng theo mình nghĩ các package nhỏ là để làm những công việc chuyên biệt còn enterprise là bản full.

http://www.vn-zoom.com/f228/cau-hinh-nhanh-php-mysql-voi-apache-15519.html
đây là web mà mình đã tham khảo.tất nhiên là rất nhiều (google mà :> nhưng mình nghĩ zoom có uy tín nên mình làm theo.

error thì không có. chỉ có mỗi cái là sau khi edit 2 file php.ini + htdds thì không bật được apache.

nó chỉ thông báo đơn thuần là không khởi động được chứ không có error nào hết

bạn thử click chạy trực tiếp cái apache\bin\httpd.exe chứ không chạy từ service nhé , nó sẽ thông báo lỗi cụ thể hơn.

khi cài php từ bộ zip, bạn copy file libmysql.dll trong thư mục php sang thư muc apache\bin , phần còn lại bạn làm theo hương dẫn của php readme, bạn làm thử nếu có vấn đề gì thì post lỗi trong log của apache lên đây nhé.

bạn tham khảo cách làm ở đây nhé:
http://www.newty.de/fpt/fpt.html#chapter2
http://www.newty.de/fpt/callback.html#member

nếu bạn HoS vẫn thấy chưa thỏa đáng thì thử xem lại bash history xem lúc trước đã gõ gì vào nào smilie