|
|
mysqld là service, nó sẽ run từ khi được start lên cho đến khi được stop, khác với các process chạy theo kiểu "on demand" như các process php-cgi.
Bạn nên biết access log có trường thông tin về "request processing time" ?
Nếu là mình, mình sẽ:
1. Xem access log xem "resource" (tham khảo nghĩa trong mô tả RESTful) nào có thời gian xử lí lâu (trên 1 phút hoặc hơn, bạn theo dõi xem các process đó chạy trong bao lâu).
2. Audit lại source code nếu cảm thấy bất thường
|
|
|
@concobe: bạn kiểm tra vì sao các script php của bạn lại mất hơn cả phút để thực thi ? Trong hình chỉ có 2 process php-cgi nhưng mà mất hơn phút cho mỗi process như vậy thì không ổn !
Hãy thử tìm hiểu nguyên nhân vì sao, bắt đầu bằng việc tìm ra script nào làm chậm và tốn CPU như vậy
|
|
|
Password còn lưu trong Router, bạn chỉ việc login vào Router và export config ra để backup, mở file backup đó lên tìm chuỗi password, thông thường thì nó là chuỗi encoded base64, mà đã encoded thì decode được !
Đó là cách mình dùng khi đổi Router, vì router nhà mạng cho dỏm quá, mình có con Router xịn nên thay con khuyến mãi, sau đó là fake Mac và dựa vào cấu hình cũ để cấu hình lại Router mới
|
|
|
Như đã nói, bạn cần thống kê CCU để biết là lượng CCU thực sự cao hay là bị attack !
Thấy có nhiều MySQL connection thì bạn cần:
1. Xem xét kích thước DB của bạn
2. Mỗi quan hệ giữ các tables
3. Cấu trúc các tables và lượng records bên trong chúng
=> Sẽ cho thấy việc thiết kế có hợp lí hay không, và cần tối ưu ở đâu.
Ngoài ra, cố gắng sử dụng cache để đỡ gánh cho DB, bằng các cách sau ưu tiên trên xuống:
1. Tối ưu nhất: code lại site, sử dụng cache triệt để.
2. Vì site của bạn theo mình thấy dữ liệu read-only nhiều hơn write, vậy tách xử lí read write ra, sử dụng moddule memcached của NGINX (Apache mình không chắc có không) để cache URL
3. Cache query từ MySQL
4. Cache opcode của PHP
Mình vẫn không thể khẳng định site của bạn bị DDoS chỉ với vài thông tin sơ sài như vậy
|
|
|
Hi all,
Ngày xưa làm trong mấy cty có chính sách PDL, bị FW chặn tứ phía, mình hay cấu hình lại route là xài okay, vì suy cho cùng nếu bạn sử dụng một ứng dụng cho nhiều nguồn tài nguyên thì ... gãy ? VD mở outlook check mail công ty thì xài Line nội bộ, đồng thời Outlook cũng check cả mail cá nhân thì sao ?
Việc cấu hình lại bảng định tuyến tuy mất chút thời gian ban đầu, nhưng lưu lại thành script thì mỗi lần cần thì run cú là xong
Anyway, bạn có thể lựa chọn giải pháp nào phù hợp và tiện dụng nhất với bạn ^^
|
|
|
Hi,
Nếu đã chấp nhận cách giải quyết đó, thì bạn có thể tham khảo 2 link sau để hạn chế tài nguyên ứng với mỗi user:
http://www.cyberciti.biz/tips/linux-limiting-user-process.html
http://www.cyberciti.biz/faq/cpu-usage-limiter-for-linux/
Cheer
|
|
|
VPS 2GB mà HTTPD 2G+ và MYSQL 2G+ thì có 2G+ nằm trên swap rồi ?
Bạn cung cấp con số thời điểm đó mà không cung cấp con số thời điểm khác và mức tăng trưởng thì mình cũng không đủ thông tin để nói được gì.
Cần vài biểu đồ sử dụng tài nguyên, là có cơ sở để nói tiếp, ngoài bạn có hệ thống cảnh báo khi server hight-load ko ?
|
|
|
Hi tuanksor,
Cái module rlimit chỉ hỗ trợ limit resource của từng process của apache khi handle request, không giải quyết được vấn đề của bạn. Như anh quanta nói, hiện nay vẫn không có module nào của apache giải quyết việc này. Tuy nhiên:
Xưa nay việc quản lí tài nguyên là do OS đảm nhiệm, vậy tại sao lại bắt Apache đi làm nhiệm vụ của OS ??
Quay lại vấn đề của bạn, nếu bạn chia bài toán của bạn thành 2 bài toán nhỏ sau:
1. Bắt Apache sử dụng user account để xử lí yêu cầu, tất nhiên làm được.
2. Quản lí tài nguyên sử dụng bởi từng user, việc này hoàn toàn làm được.
Vậy bài toán của bạn đã được giải quyết, mà theo mình là cách đúng đắn nhất !
Đừng bắt dân đen làm chính trị, hỏng đấy
|
|
|
Có 2 cách cho bạn:
1. Đơn giản nhất, sử dụng VPN, tốn chút phí nho nhỏ nếu muốn dịch vụ tốt.
2. Cách dân gian hay làm, xem phần "defense": http://en.wikipedia.org/wiki/ARP_spoofing, đòi hỏi nhiều kĩ thuật và tốn công hơn.
Về cách sử dụng VPN thì có ưu điểm là nếu bạn vác con laptop/tablet/mobile ra cafe ngồi thì cũng được an toàn, còn đối với set ARP tĩnh thì ...
Mình xưa giờ cứ ra khỏi nhà là vào VPN cho an toàn, thiết nghĩ một Private VPN Account speed tốt thì tốn chút phí để an tâm cũng đáng
|
|
|
Mấy gói của bạn bự quá, mấy chục MB ai mà coi ?
Dựa vào đâu mà bạn xác định quá tải HTTPD và MySQL ?
Trước mắt là bạn có hệ thống monitor không ? Nếu không thì mình có thể cho bạn account trên hệ thống monitor Zabbix của mình, bạn chỉ cần cài zabbix-agent và cấu hình cho nó gởi về zabbix-server của mình mà theo dõi hệ thống, từ mức load CPU, Network cho đến Disk, RAM ...
Rồi mình sẽ tư vấn và hỗ trợ thêm trên số liệu thật !! Chứ bạn capture cả khối vậy sao mà xem cho xuể !!
~~
LNH
|
|
|
Nếu hệ thống của cty bồ có sử dụng proxy để kiểm soát việc truy cập của nhân viên thì việc bồ bị theo dõi và bị cảnh báo khi lướt web sa đà là chuyện đương nhiên ! Có gì mà phải thắc mắc ?
|
|
|
Dupe !! Mấy nay HVA sao thế nhỉ, rất chập chờn dù cái homepage vào rất nhanh
Mod xoá hộ bài dupe này nhé !
Thanks.
|
|
|
heroandtn3 wrote:
Chào anh quanta,
Em đã đọc một số bài viết về SUID và SGID cũng như bài viết của anh và biết được rằng khi 1 file được gán SUID thì lúc thực thi, file đó sẽ được thực thi y như khi thực thi dưới quyền ower của nó.
Em cũng đọc thử một vài ví dụ nhưng khi làm theo thì không thành công.
Em có 2 file như sau:
Code:
-rw-r--r-- 1 root root 56 Nov 3 11:01 abc
-rwsr-sr-x 1 root root 294 Nov 3 11:13 root.sh
Nội dung của file root.sh chứa lệnh: echo `date` >> abc
Tuy nhiên khi em thực thi file root.sh với quyền người dùng bình thường thì không sửa thành công file abc mà báo lỗi:
Code:
$ ./root.sh
./root.sh: 8: ./root.sh: cannot create abc: Permission denied
Em hiện đang dùng HĐH Ubuntu 12.04.
Anh và mọi người có thể giải thích tại sao khi em chạy file root.sh nó lại không thực thi thành công không ạ?
File root.sh của bạn là một file script, không phải file binary, do đó nó cần interpreter để thực thi kịch bản bên trong nó. Nghĩa là khi bạn ./root.sh thì thực ra lệnh đó sẽ được run như sau:
Code:
/bin/sh root.sh
hoặc
/bin/bash root.sh
Bật SUID cho sh/bash và thử lại xem
|
|
|
Em nghĩ đặt Snort trước Fw là do SnortSam chỉ làm nhiệm vụ phân tích và gửi command tới fw và việc chặn IP nào là trách nhiệm của IP. Nếu đặt Snort sau thì liệu cuộc xâm nhập "đã thành công rồi" và SnortSam lúc này chỉ có thể "alert" thôi mà ko thể gửi cảnh báo để fw chặn được nữa, vậy liệu chức năng Active Response có còn tác dụng nữa hay ko a?
Có lẽ khi bạn đọc tài liệu về snortsam và diễn dịch sang tiếng Việt có nhầm lẫn dẫn đến bạn hiểu không đúng vai trò của snortsam. Tuy nhiên ngay cả khi bạn dịch sai, bạn không thấy có gì đó bất ổn khi snortsam làm-nhiệm-vụ-phân-tích ? Thế snort sẽ làm gì nếu không có snortsam ? Và đó cũng là thắc mắc của mình với giả định của bạn.
Để kiểm chứng, mình tải source snortsam về và xem xét, kết quả như sau:
Code:
* This is the remote module that listens for snort alerts generated with the
* Alert_FWsam plug-in. This module provides secure gateway functionality between
* the snort alerts and various firewalls. It listens to the snort alerts, and can
* invoke a block on following firewalls:
...
... các loại firewall được support. Kèm theo các function cho từng loại, loại nào connect ra sao ...
Vậy, nó là một remote module, chạy độc lập như một service và nhận alert từ snort (bạn cần patch snort để gởi alert cho snortsam), sau khi nhận alert từ snort, snortsam sẽ thực hiện "nối kết" vào các firewall để "nhờ chặn hộ".
Tóm lại là, bạn chưa đọc đến đoạn triển khai snortsam như thế nào, tìm hiểu sơ sài vậy thì ỷ lại quá !!
|
|
|
sleeper wrote:
Mình nhớ không nhầm thì quanta lúc trước cũng ra bắc vào nam vì chuyện việc làm.
Có ích gì cho topic không ? Thế theo sleeper thì cứ ở cái ao làng mà xin việc nhỉ ?
Quay lại chủ đề. Rút ra từ quá trình của mình, thì có 3 cách để bạn đảm bảo cho tương lai có việc làm tốt:
1. Học chăm chỉ, du học càng tốt, blah blah nói chung là bằng cấp càng nhiều học vị càng cao càng tốt.
2. Xây dựng Porfolio của bạn bằng những đóng góp có ích cho cộng đồng, thực ra cũng là một cách thể hiện khả năng của bạn.
3. Cả 2 cách trên. Vì sao có cách này ? Vì không phải mọi người đều học để làm một cái gì đó !
Chung quy là cần một sự thừa nhận từ xã hội
|
|
|
Chào bạn,
Để đơn giản, SnortSam, bạn hãy xem nó là cầu nối để Firewall nhận message Snort và tiến hành block IP tương ứng, vậy là đủ.
Tuy nhiên như trong mô hình (1) thì Snort đứng sau iptables, các packet khi tới Snort thì đã đi qua iptables mất rồi.
Đây là một câu hỏi rất ngay ngô, thế bạn nghĩ nếu để Snort ở trước Firewall thì bạn cần SnortSam để làm gì ?
Snort cung cấp các tính năng phân tách và đối soát dữ liệu lưu thông trên mạng cao hơn Firewall, và nó dùng để phát hiện (và ngăn chặn) các hành động "tinh vi" hơn là những "bất thường" của network.
Do đó việc đặt Snort trước FW sẽ làm cho Snort phải chịu tải lớn không cần thiết, và quá trình "kiểm tra cái thứ đã biết rồi" đó cứ lặp đi lặp lại, đáng không ? Đổi lại nếu FW ở trước lọc một phần các dữ liệu bất hợp lệ, sau đó Snort phát hiện các "thủ đoạn tinh vi" và gởi đến FW để chặn ngay từ đầu. Đến giờ mình cũng chưa thấy TH nào đặt Snort trước FW cả
Và trong mô hình test thử em có thể bố trí (snort, snortsam, iptables) chung trên một máy ảo được không ạ.
Câu trả lời là được. Tuy nhiên cần tỉnh táo khi xử lí trên các interface và routing data
------
Bổ sung về vị trí đặt Snort, nên đặt ở 3 và 4.
|
|
|
Vậy thì rõ ràng là các shell script này phải được interpret bằng một shell nào đó phải không các bạn?
Cái này đúng. Các script này luôn có chỉ định interpreter ở đầu, và được chmod +x. Interpreter đó sẽ được gọi khi init process gọi thực thi các script đó. Tuy nhiên init process không có "kill" (bash/sh/...) sau đó mà chính là script trong rc?.d với "exit" ở cuối script.
Về suy luận, bạn đã đi đúng hướng, chỉ có một chút nhập nhằng ở chỗ shell thôi. Shell vừa là interface tương tác giữa user và OS, nhưng bản thân nó cũng là một interpreter. Trong TH trên, nó được sử dụng như một interpreter
|
|
|
Cái này không phải lỗi của ứng dụng, có thể lỗi của người cấu hình hệ thống. Vì:
1. Thông báo ở trên là vì ứng dụng không thể query database được nữa vì khi tạo user với một lí do nào đó user được tạo ra được set max_questions (là một số X khác 0). Nghĩa là user này chỉ query được X lần và sau đó sẽ không query được nữa, gặp tình trạng như trên.
2. Việc để lỗi phun phèo phèo như vậy có thể do deployer không set lại Deploy Environment từ Test sang Production.
Kết luận: Với sự tình như trên, không khai thác được nhé, nếu muốn khai thác thì tìm lối đi khác
|
|
|
Bạn lưu ý rằng trường "cached" trong output của "free -m" là lượng bộ nhớ được dùng để cache kết quả, và nó sẽ được thu hồi ngay khi hệ thống cần. Do đó, trong trường hợp này, thực sự hệ thống của bạn đang có 52 (free) + 1390 (cached) = 1442 MB bộ nhớ avaible. Và thực sự hệ thống của bạn chỉ charge 568 MB bộ nhớ thôi.
Bạn yên tâm nhé
|
|
|
ngocson2vn wrote:
Với mỗi runlevel các đoạn scripts được chạy để khởi động từng dịch vụ riêng biệt, thay vì một số lượng lớn các file phải chỉnh sửa bằng tay. Những đoạn scripts này được đặt trong thư mục /etc/rc.d/init.d, và phần lớn đều có một tuỳ chọn start hoặc stop.
Bạn quanta cho mình hỏi là trong lúc hệ thống đang boot thì những scripts này được chạy. Vậy những scripts này được chạy bằng cách nào? Vì thông thường sau khi một user login thành công thì shell của user mới được chạy và từ đó user mới có thể chạy được các scripts thông qua shell của mình.
Liệu có phải trong lúc các init scripts được gọi thì có một shell nào đó phải được chạy? Vậy thì shell này là shell của root user phải không bạn? Và sau khi shell này chạy xong thì nó có bị kill đi không và cái gì đã kill nó hay là nó tự exit?
Thanks
Bạn này đang nhập nhằn với khái niệm shell
Thực ra shell là vỏ cung cấp khả năng tương tác của người dùng với OS. Đối với các tác vụ hệ thống gọi lẫn nhau thì đâu nhất thiết phải có shell mới được.
Trong Linux, về lí thuyết thì các process sinh ra được đánh thứ tự từ 0 và tăng dần cho đến khi "đụng trần" thì nó lặp lại từ 0 và ... Tuy nhiên, có process id không bao giờ được recycle trừ khi reboot hệ thống, đó là process có PID = 1, init process.
Quá trình boot kết thúc bằng việc định danh process init với PID = 1, và việc còn lại để "lôi" các thứ còn lại là của process init này, và tất nhiên nó chính là process đọc /etc/inittab và làm các thứ còn lại như anh quanta đã trình bày ở trên
P/S: riêng về việc gọi process này thì mình gọi nó là "process chúa" thay vì "ông nội" hay "cha" như anh quanta
|
|
|
hungbn5 wrote:
Vậy e cần phải làm gì để tối ưu hoá nó hả anh . E đã giảm thời giàn timeout của apache và nhưng vẫn ko ăn thua ! khi f5 liên tục server vẫn load rất cao . e phân vân ko pít phải code CI của e có vấn đề ko ! Mong a giúp e vấn đề này với
Mình bảo xem log mysql xem nguyên nhân có phải nhiều connection nên mysql từ chối tạo thêm kết nối hay không, bạn vẫn chưa làm ?
Điều quan trọng nhất là độ lớn của site bạn, nói chính xác là độ lớn của database. Vì sao ?
1. Xem output top của bạn, mysqld sử dụng 251.5% CPU trong khi các process PHP toàn dưới 1%.
2. Bạn thuê gói VPS lớn, chứng tỏ lượng data và mức tải tương đối lớn.
Lẽ ra bạn nên theo dõi trong thời gian test và cung cấp con số lên đây để tránh trường hợp chụp đúng lúc nó low load, sau khi chạy top thì bấm thêm phím 1 để có chi tiết từng CPU
Lưu ý: theo dõi bình thường, không "dí" F5 nữa nhé !
Giả định từ lệnh top của bạn, dựa vào I/O waiting gần như 0%, nghĩa là CPU load cao nhưng không nghẽn IO, cộng thêm thời gian xử lí một request như bạn nói là dưới 1s nên DB của bạn vẫn chưa bị overload. CPU của bạn load cao trong thời gian xử lí là hoàn toàn bình thường. Nếu khách hàng của bạn gặp nhiều lỗi không thể kết nối data như CI thông báo ở trên, bạn vui lòng xem lại recommend của mình ở bài trước.
Nếu mysqld của bạn thực sự bị overload thì lên đây ta tiếp tục
Bạn cũng nên theo dõi các slow query bằng cách bật slow query log (tham khảo từ document của mysql).
|
|
|
30 cái CLOSE_WAIT
Đây chính là cái mình nói ở mục 2, các connection ở server chờ client gởi FIN để đóng kết nối trả resource cho hệ thống, mà chờ hoài không thấy nên sẽ đợi hết timeout hệ thống mới thu hồi, nên việc bạn test kiểu này cũng không thực sự có đúng kết quả mong muốn nếu muốn đo khả năng chịu tải của hệ thống.
Unable to connect to your database server using the provided settings.
Đây là thông báo lỗi chung khi không connect được đến DB (ở đây là mysql) của CI, có nhiều khả năng gây ra, và trong TH này mình đoán là chạm ngưỡng max connection của mysql, nhưng để chắc chắn, hãy xem log của mysql và so sánh với cấu hình (file config) đang chạy của mysql.
|
|
|
Thực ra mà nói là thông tin ít ỏi như vậy khó mà "phán" cho đúng !
Nếu mình là sys@ssmin thì mình sẽ:
1. Kiểm tra thời gian đáp ứng một request là bao nhiêu, kèm theo độ load của CPU khi xử lí 1 hoặc 2 request để xem mức load và tốc độ xử lí của VPS như thế nào.
2. Cái việc bạn F5 liên tục làm cho các connection phải chờ timeout để close, resource tốn đáng kể đấy. Xem output lệnh "netstat -tulpan | grep :80" để biết thêm thông tin.
3. Nếu CPU xử lí chậm thì với 2 điều kiện trên dẫn tới server đuối nếu tốc độ giải quyết request chậm hơn tốc độ gởi request của client.
Vì ít thông tin nên "nhắm mắt đoán mò" như trên, "mò" ra thông tin thì "phán" tiếp
|
|
|
lỗi này có thể do code trên website không nhỉ ?
Các sự cố như này mình từng gặp thường là do code ẩu, để kiểm tra có đúng hay không, bạn cần thống kê log truy cập.
Ví dụ: trong access_log có trường thông tin về "response time" (ý mình là thời gian xử lí và trả kết quả cho client) không ? Theo dõi và thống kê các resource có "response time" cao và audit chúng nó
Update:
%T - Time taken to process the request, in seconds
http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html#Access_Log_Valve/Attributes
|
|
|
Vấn đề không phải ở /etc/security/limits.conf, vì bạn nâng limit lên nhưng lượng file được mở ra cứ tăng lên thì một lúc nào đó nó vẫn chạm ngưỡng, việc nâng ngưỡng chỉ làm chậm thời gian báo lỗi thôi
Bạn xem lại "Dạo này" có gì thay đổi so với "trước đây" không ?
|
|
|
tranhuuphuoc wrote:
Ủa, sao thư mục vtigercm này để ở máy khác chi vậy cà, sao không để nó trực tiếp trên server, muốn code thêm thì dùng IDE chẳng hạn Komodo-IDE khi nào sửa code thì đăng nhập trực tiếp vào server mà chỉnh luôn cho dễ dàng.
Chẹp, xì tai dân Network - System
Về nguyên tắc Developer không được phép change code trực tiếp trên production, phải code-deploy-test ở môi trường test rồi commit final lên subversion. Sys@ss (kiêm deployer) sẽ export và deploy lên production
Về giải pháp thì mình dùng GlusterFS http://www.gluster.org
|
|
|
|
|
|
|