banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Messages posted by: consoko  XML
Profile for consoko Messages posted by consoko [ number of posts not being displayed on this page: 1 ]
 
eat swap gần 800MB kìa bạn, add thêm Ram đi.
swap đang chạy tới 5GB kìa bạn, kiểu này đường nào ko treo server. Upgrade thêm Ram đi nha bạn. Check lại code php và compile lại apache và php với cấu hình thích hợp nhất xem sao nhé.

quanta wrote:

consoko wrote:

The advantage of the brackets now is that the string "firefox" no longer appears in the grep command. Hence, grep itself won't show up in the grep result.

http://askubuntu.com/questions/153419/how-does-this-tricky-bracket-expression-in-grep-work
 

Có thể tóm tắt lại theo ý hiểu của bạn được không? Regular Expression này sẽ được thằng nào xử lý nhỉ: `bash` hay `grep`?

consoko wrote:

@quanta tiếp tục đặt những câu hỏi đi, qua những câu hỏi của bạn mình cũng phát hiện thêm nhiều điều lý thú. 

Câu hỏi chính vẫn còn nằm ở bên trên mà:
- Khi một request đi đến server, Apache sẽ tạo ra một process mới để xử lý hay là thế nào?
- Multi-Processing Module là gì? Có những loại chính nào? Ưu, nhược điểm của từng loại?  
 


- Regular Expression được xử lý bởi bash. Vì mình chú ý, khi viết regular expression sai cú pháp thì bash sẽ show lỗi ra bash: can not interpreter (đại loại như vậy) smilie

- Khi request đến server web. Nếu vẫn còn dư process trống thì apache sẽ sử dụng những process này để phục vụ request. Nếu hết thì nó sẽ fork 1 process mới để xử lý. (còn cơ chế limit và spare process thế nào. mọi người đọc tài liệu về mpm module nhé).

- Còn về mpm thì apache có 3 modules, nhưng mình chỉ bàn tới 2 modules chính là prefork and worker.
+ Prefork sử dụng process để xử lý request, sử dụng memory riêng cho từng process. Do đó nó sẽ chậm hơn và tốn nhiều tài nguyên hơn so với thread do cơ chế fork process. Nhưng stable hơn vì sử dụng memory riêng nên 1 process bị chết sẽ ko ảnh hưởng tới những process khác.
+ Worker sử dụng thread để xử lý process. Các thead do 1 process sinh ra sẽ sử dụng chung memory với nhau. Nếu 1 một thread bị chết sẽ ảnh hưởng đến toàn bộ thread trong một process. Đây là lý do không thể sử dụng PHP + worker + mod_php. Cũng do những đặc điểm trên nên thread sẽ nhanh hơn và chạy ít tốn tài nguyên hơn.
Bạn lọc bớt comment đi chứ nhìn vô là hết muốn đọc:

cat [configfile] | grep -v "^ *#" | grep -v "^$"

quanta wrote:

Câu hỏi đặt ra là: tại sao `ps -ef | grep [h]ttpd` lại không trả về chính bản thân `grep` process; có gì bí hiểm xung quanh dấu ngoặc vuông này nhỉ?  


The advantage of the brackets now is that the string "firefox" no longer appears in the grep command. Hence, grep itself won't show up in the grep result.

http://askubuntu.com/questions/153419/how-does-this-tricky-bracket-expression-in-grep-work

@@@quanta tiếp tục đặt những câu hỏi đi, qua những câu hỏi của bạn mình cũng phát hiện thêm nhiều điều lý thú. Thanks. smilie
- Bạn sử dụng lệnh httpd -l xem apache trên 2 máy install module như nhau ko
- Và lênh pmap `pidof httpd` xem thử httpd load gì lên và so sánh nhé.
Tại vì độ trễ của Network nên tcp không thể đóng kết nối ngay lập tức để chờ những gói tin còn lại nếu có, nó phải chờ một khoảng thời gian time-out để đống kết nối hoàn toàn (CLOSED) sau khi connection đã ở tình trạng close (TIME_WAIT).

Theo như tài liệu thì net.ipv4.tcp_tw_reuse=1 sử dụng connection ở trạng thái TIME_WAIT để phục vụ new connection. Nếu vậy,
- B1: telnet đến một con server port 80. ===>>> 1 connection ESTABLISHED
- B2: ngắt kết nối. ===>>> TIME_WAIT
- B3: connect lại tới server port 80. ===>>> tạo 1 connection ESTABLISHED mới và connection cũ vẫn ở trong tình trạng TIME_WAIT
Đáng lẽ tại B3, connection TIME_WAIT phải đc sử dụng để phục vụ connection mới chứ nhỉ.

smilie
Bạn sử dụng keyword haproxy hoặc nginx nhé.

quanta wrote:
- Firefox trên Ubuntu. Đã enabled JavaScript và Remember History.
- Sau một (vài) lần vào HVA, lần sau chỉ cần gõ vài chữ "hva..." rồi enter thì tính năng Auto-complete tự wwwect sang https://www.hvaonline.net/. Click tiếp vào Forum hay Portal thì sẽ bị vào... https://www.hvaonline.net/null/.

 


Trên firefox của mình hiện giờ cũng dính lỗi này, chuyển qua null không thể vào dc nhưng xài chrome thì bình thường.
Theo mình thì không nên tắt query cache, thay vào đó mình nên điều chỉnh nó ở hợp lý với performance của mình. Tốt nhất nên thay thế luôn bằng memcache. smilie

Đây là 1 bài viết về đề high memory đối với query cache

Code:
http://www.mysqlperformanceblog.com/2007/03/23/beware-large-query_cache-sizes/
Mình đang test chức năng content switching nhưng gặp vấn đề khó hiểu như sau. Mong mọi người giải đáp giúp.

Rule switching mình config như thế này (giống trong manual của Haproxy)

Code:
acl url_static path_beg /static /images /img /css
acl url_static path_end .gif .png .jpg .css .js
acl host_www hdr_beg(host) -i abc.com
acl host_static hdr_beg(host) -i img. video. download. ftp.
# now use backend "static" for all static-only hosts, and for static urls
# of host "www". Use backend "www" for the rest.
use_backend static if host_static or host_www url_static
use_backend www_example_com if host_www
#default_backend www_example_com


- Backend để phục vụ static file mình sử dụng Nginx.
- Backend www_example_com mình sử dụng Apache để phục vụ php.
Vấn đề là hầu hết static file đã được switch tới đúng Nginx, chỉ riêng những file này là vẫn còn chạy tới Apache:

Code:
192.168.9.245 - - [06/Aug/2012:07:26:10 +0700] "GET /image.php?image_abc.com.jpg&width=110&height=70&image=images/abc.com/abc1.png HTTP/1.1" 304 -
192.168.9.245 - - [06/Aug/2012:07:26:10 +0700] "GET /image.php?image_abc.com.jpg&width=110&height=70&image=images/abc.com/abc2.png HTTP/1.1" 304 -
192.168.9.245 - - [06/Aug/2012:07:26:11 +0700] "GET /image.php?image_abc.com.jpg&width=110&height=70&image=images/abc.com/abc3.png HTTP/1.1" 304 -
192.168.9.245 - - [06/Aug/2012:07:26:11 +0700] "GET /image.php?image_abc.com.jpg&width=110&height=70&image=images/abc.com/tichluy.png HTTP/1.1" 304 -
192.168.9.245 - - [06/Aug/2012:07:26:11 +0700] "GET /image.php?image_abc.com.jpg&width=110&height=70&image=images/abc.com/toaky6.gif HTTP/1.1" 304 -
192.168.9.245 - - [06/Aug/2012:07:26:11 +0700] "GET /image.php?image_abc.com.jpg&width=110&height=70&image=images/event/abc4.png HTTP/1.1" 304 -
192.168.9.245 - - [06/Aug/2012:07:26:11 +0700] "GET /image.php?image_abc.com.jpg&width=110&height=70&image=images/abc.com/thangcap2.gif HTTP/1.1" 304 -


Theo mình hiểu những file trên sẽ match rule này: use_backend static if host_static or host_www url_static
để chạy tới Nginx, nhưng nó vẫn nhảy vào Apache smilie smilie smilie

Mình cũng đang ngâm cứu optimize Mysql. Nên trả lời Quanta xem thử đúng không.

Mysql đã enable query cache nhưng thông số Qcache_not_cached quá lớn so với Qcache_queries_in_cache và memory cho Query cache vẫn còn nhiều ===>>>> không hiệu quả. Ở đây mình đề xuất tăng query_cache_limit lên vì query có thể lớn hơn query_cache_limit ===>>> không thể cache được.
Bị lỗi ở đâu vậy bạn
Update lên kernel-PAE mới nhất và vấn đề đã được giải quyết. Thanks mọi người.
Thanks bạn, vấn đề là mình muốn tìm hiểu lỗi này nguyên nhân do đâu. Việc cai lại bản 64 bit mình cũng đã lên plan rồi.
Máy chủ web của mình có 8GB RAM nhưng chỉ run được trên 2GB (trước đó thì dùng hết 8GB). Đã search 1 vòng với google nhưng rất mơ hồ và chưa có hướng giải quyết, bác nào có hướng khắc phục giúp em với ah:

Đây là một số thông tin trên server web của em:

Code:
uname -a
Linux xxx 2.6.18-128.1.14.el5PAE #1 SMP Wed Jun 17 07:15:54 EDT 2009 i686 i686 i386 GNU/Linux


Code:
MemTotal: 8309312 kB
MemFree: 6189224 kB
Buffers: 203608 kB
Cached: 1536812 kB
SwapCached: 0 kB
Active: 1731816 kB
Inactive: 305572 kB
HighTotal: 7470876 kB
HighFree: 5622776 kB
LowTotal: 838436 kB
LowFree: 566448 kB
SwapTotal: 4096564 kB
SwapFree: 4096564 kB
Dirty: 5852 kB
Writeback: 0 kB
AnonPages: 296856 kB
Mapped: 21092 kB
Slab: 62500 kB
PageTables: 7508 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 8251220 kB
Committed_AS: 539312 kB
VmallocTotal: 116728 kB
VmallocUsed: 4992 kB
VmallocChunk: 111660 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB



Code:
total used free shared buffers cached
Mem: 8114 2039 6075 0 198 1500
-/+ buffers/cache: 339 7774
Swap: 4000 0 4000


Code:
Nov 7 02:04:50 xxx kernel: Free pages: 282688kB (512kB HighMem)
Nov 7 02:04:50 xxx kernel: Active:23950 inactive:1951246 dirty:0 writeback:0 unstable:0 free:70672 slab:7237 mapped-file:1284 mapped-anon:1981624 pagetables:12335
Nov 7 02:04:50 xxx kernel: DMA free:12188kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16384kB pages_scanned:0 all_unreclaimable? yes
Nov 7 02:04:50 xxx kernel: lowmem_reserve[]: 0 0 880 9200
Nov 7 02:04:50 xxx kernel: DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
Nov 7 02:04:50 xxx kernel: lowmem_reserve[]: 0 0 880 9200
Nov 7 02:04:50 xxx kernel: Normal free:269988kB min:3756kB low:4692kB high:5632kB active:1536kB inactive:491168kB present:901120kB pages_scanned:1468136 all_unreclaimable? yes
Nov 7 02:04:50 xxx kernel: lowmem_reserve[]: 0 0 0 66560
Nov 7 02:04:50 xxx kernel: HighMem free:512kB min:512kB low:9396kB high:18284kB active:94264kB inactive:7313816kB present:8519680kB pages_scanned:12459933 all_unreclaimable? ye
s
Nov 7 02:04:50 xxx kernel: lowmem_reserve[]: 0 0 0 0
Nov 7 02:04:50 xxx kernel: DMA: 3*4kB 2*8kB 4*16kB 4*32kB 3*64kB 2*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 2*4096kB = 12188kB
Nov 7 02:04:50 xxx kernel: DMA32: empty
Nov 7 02:04:50 xxx kernel: Normal: 1*4kB 0*8kB 6*16kB 8*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 65*4096kB = 269988kB
Nov 7 02:04:50 xxx kernel: HighMem: 30*4kB 1*8kB 0*16kB 0*32kB 2*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 512kB
Nov 7 02:04:50 xxx kernel: 1807 pagecache pages
Nov 7 02:04:50 xxx kernel: Swap cache: add 1025926, delete 1025685, find 581/825, race 0+1
Nov 7 02:04:50 xxx kernel: Free swap = 0kB
Nov 7 02:04:50 xxx kernel: Total swap = 4096564kB
Nov 7 02:04:50 xxx kernel: Free swap: 0kB
Nov 7 02:04:50 xxx kernel: 2359296 pages of RAM
Nov 7 02:04:50 xxx kernel: 2129920 pages of HIGHMEM
Nov 7 02:04:50 xxx kernel: 281968 reserved pages
Nov 7 02:04:50 xxx kernel: 329023 pages shared
Nov 7 02:04:50 xxx kernel: 241 pages swap cached
Nov 7 02:04:50 xxx kernel: 0 pages dirty
Nov 7 02:04:50 xxx kernel: 0 pages writeback
Nov 7 02:04:50 xxx kernel: 1284 pages mapped
Nov 7 02:04:50 xxx kernel: 7237 pages slab
Nov 7 02:04:50 xxx kernel: 12335 pages pagetables
Nov 7 02:04:50 xxx kernel: Out of memory: Killed process 27014 (httpd).


Thanks for read
Lúc trước FF của mình cũng bị tình trạng này, mới phát hiện ra FF bị xung đột với chg trình Credential Manager trên máy laptop.
Anh PXMMRF cho em hỏi tại sao khi mình thay hdd bị hư bằng một hdd khác khi hệ thống đang chạy sẽ dẫn tới 2 hdd đều bị hư ah.
Tại em cũng đang xài dòng ibm, thay nhiều lần rồi mà chưa thấy bị hứ hdd smilie, chỉ thấy sync data qua ổ mới không được thôi, sau khi reboot và insert hdd mới vô thì mới sync được.
Mình đang muốn thiết kế một hệ thống giám sát toàn bộ hệ thống mạng bao gồm server, db, đường truyền, web....và khi có sự cố xảy ra sẽ gửi alert bằng message đến điện thoại của mình. Bạn nào biết giúp mình giải pháp trên cả linux và windows với:

1. Mình cần dùng phần mềm nào để thực hiện việc này.
2. Mình cần mua thêm thiết bị gì để gửi tin SMS.

Cảm ơn đã đọc.
Bác mua laptop HP Business 6910p mà xài, tầm 15tr. Bảo hành chính hãng 3 năm. Dòng này cực kỳ bền nhé. Link review của e nó, bác xem qua nhé
Code:
http://forum.notebookreview.com/showthread.php?t=140343


Thành thực khuyên bác đừng nên mua dòng HP DV, cực kỳ chuối. Mình xài 2 dòng DV 2x và 6x của hp rồi, sau đó phản bán tháo. Hiện tài xài 6910p, rất hài lòng. smilie
Đọc cái link tôi gửi đi bác, có chứa tất cả thông tin cần thiết để trả lời cho bác đó.
Lỗi Null Session bị lợi dụng để enumeration.

Mặc định trong windows 2003 và xp đã ngăn chặn việc enumeration user và group nhưng cho phép enumeration các ổ đĩa share.

File .reg nói trên dùng để disable share mặc định của Windows, qua đó chặn luôn lỗi enumeration share.

Chi tiết về null session bạn có thể đọc tại đây:
http://web.mit.edu/is/topics/windows/server/winmitedu/security.html#null

StarGhost wrote:
Ồ, thực ra thì điều này cũng dễ hiểu thôi. Khi bạn gửi một packet đến một peer mới kết nối vào mạng, thì switch sẽ broadcast packet này, dẫn đến việc switch nhận định sai về port mà nó dùng để kết nối đến máy của bạn. Vì vậy khi cái peer kia gửi packet đến máy bạn, nó sẽ mãi mãi bị gửi vào cái port sai (mãi mãi là vì khi gửi đi nó sẽ quay lại switch và lại bị gửi đi).

Như vậy bạn có thể gửi packet đi đến peer nhưng không thể nhận được packet từ peer gửi lại. Tuy nhiên nếu MAC của máy bạn và peer xuất hiện trên CAM table của switch ngay từ đầu thì không có vấn đề gì. 


Câu trả lời của StartGhost có liên quan gì tới câu hỏi trên đâu nhỉ.
Khi 2 host giao tiếp với nhau trên mạng, nếu lần đầu tiên nó sẽ broadcast gói tin, destination host sẽ trả lời gói tin broadcast này. Vậy việc này đâu có liên quan gì tới hiện tượng ở trên đâu.

@huan_ng: collision domain là chỉ 1 vùng ở đó các host có khả năng đụng độ khi truyền dữ liệu vậy thì liên quan gì tới hiện tượng bạn nói. smilie
Sử dụng kỹ thuật arp poisoning or Mac flooding để capture packet trong môi trường switch

tmd wrote:
Chủ cái topic này và những ai chạy máy ảo để được thử mùi cái thứ chuyennguoilon đó, đã cung cấp thông tin chi tiết để người khác hiểu để giúp không.

Một câu hỏi chưa trả lời là có thường xem diễn đàn không. Một câu khác là có xem thông tin về lỗi windows trên internet không. Một câu khác nữa là tại sao lại bị dính và tiền sữ xài máy trước khi dính. HỎi chừng đó câu và không nhận được chừng đó câu trả lời, mod hỏi có xài sniff xem traffic không, cũng không thấy hồi âm.

Hỏi một hồi lòi ra mặt chuột, là ít xem thông tin diễn đàn, ít sài windows, không biết cách thức cung cấp thông tin, rồi lại thích đánh trống lảnh nhách nữa. Cái vụ chính tả này nói nhiều lắm, đứng lấy nó ra làm đồ đánh trống.

 


Tui thấy từ đầu topic bác không có bài nào mang tính xây dựng, mà ra vẻ ta đây thấy ghê quá. đọc chướng chụi không nổi.

@thanhtung0811: bạn sniff đoạn traffic gửi lên đây xem thử, bạn update hết những bản vá lỗi của IE chưa?

 

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|