Các bác ơi giúp mình với. bị lỗi cả tuần mà tìm ko ra cách fix Hiện tại site mình cache 100% đa phần là cache theo query site tầm 50k người onl 1 lúc. sau khi cache thì connection tầm 150 nhưng khi xóa cache(theo từng giờ) thì nó max 1500 luôn rồi đơ luôn chẳng bao giờ xuống. (có thử tăng connect max lên 5000 thì nó tắt luôn mysql) server mình đang dùng con 400eur của online .net nên cũng gần như là max CPU so vs mấy cái khác ko nâng cấp dc - server được chia ra 1 con data - 1 con code. con data max hoài giờ ko biết phải làm sao
đã tìm dc lỗi mà ko biết sửa cách bác à xin thêm ý kiến giúp mình vs do site mình có lưu thêm comment ng dùng. được tổng comment là 500 triệu record. nặng tầm 10G- table comment. nên khi xóa cache là bản này load rất chậm mình codeigniter xóa cache_all cho thay đổi luôn cả bài viết nữa
50K online 1 lúc thì 1 ngày chắc vài triệu UV. Site tầm đó chắc 4r này không ai có để tự tin mà tư vấn. Tốt nhất em nên thuê người làm tech riêng, yêu cầu chỉnh sửa performance cho phần code và cấu hình hardware cho tốt. Load balancing mới chịu nổi chứ 1 webserver + 1 db server ko ổn với traffic như thế.
hiện tại e nghĩ ra . nên tách cái bản comment ra riêng rồi load nó theo kiểu curl được ko a. vì phải để riêng domain. mà api chỉ có curl mới đọc được đúng ko a hay còn cách nào cho e biết vs
Nếu comment em không cho ghi xuống mà chỉ có load lên thì vài triệu UV không thành vấn đề (trừ khi code cùi quá). Anh đoán nó nặng khi có thao tác ghi comment. Việc em tách ra như thế để load thì chỉ giải quyết thao tác đọc data - mà đọc data nếu em đánh index đầy đủ và chỉ query theo field index thì rất nhẹ và nhanh.
1 số trường như view, like e ko đánh vì nó thay đổi liên tục bữa thử còn nặng hơn. còn text thì ng dùng comment liên tục rồi cập nhật nên cũng khá phiền giờ e chỉ bỏ nó đi thôi mà nhẹ dc cả người. giờ tách ra rồi load như ajax thì có vẻ thấy hợp lý á a. họ cũng ko cần load quá nhanh chỉ đọc xong bài rồi comment
Cùng trường hợp như bạn có thể có nhiều loại phát sinh mà không có cụ thể ai biết giúp thế nào.Đưa lỗi chi tiết lên đi Nhiều comment quá thì cho nó thêm phân trang cũng được
Nếu khá nhanh thì vậy là OK rồi. Nhưng giải quyết bài toán tương tác nhiều với data lớn không phải chỉ đơn giản như em nói. Một lúc nào đó data nhiều hơn nữa thì lại chậm tiếp. Nên anh mới nói cần phải có người chuyên phụ trách mảng tech để em yên tâm mà phát triển web của em.
Nếu em làm theo team, trong team có 1 người giỏi tech là tốt nhất. Đương nhiên em sẽ giảm 1 phần thu nhập nhưng bù lại em có thời gian để đầu tư cho việc khác và kiếm lời từ thời gian đó. Người techinal đó không chỉ giúp em giải quyết 1 vấn đề này mà sẽ làm nhiều thứ khác. Hình thức thuê trả lương hay chia sẻ lợi nhuận là tùy em cân nhắc. Còn không thì em thuê họ xử lý đúng vấn đề mà em cần thôi. Ví dụ site em 4 triệu UV/ngày, page loading time đang là 5s. Em cần tối ưu xuống 2 giây blah blah ... Em phải có thông tin chi tiết và yêu cầu cụ thể cho người đó để họ biết họ cần làm gì và khả năng có làm được không. Ngoài ra cũng phải quan tâm việc bảo mật thông tin của bên em nữa.
nếu vậy thì em nghĩ bác nên tách phần comment ra database khác(dùng nosql, mongodb chẳng hạn) để khỏi liên quan đến data của web nữa. Ngoài ra, theo kinh nghiệm thì e thấy các site lớn họ có db cache riêng hoặc xây theo xu hướng microservice để dễ scale hơn sau này.
sau 1 thời gian tìm hiểu thì mình đoán có khi ko phải do comment =))) vì gỡ cmt mà nó vẫn đơ khi xóa cache nên nghĩ do bảng bài viết có vấn đề. vì site có 3 bản category, bài viết , user =)) mà user đã gỡ rồi bản này là bài viết. có tầm 1 triệu bài. mình nghĩ là do cách đánh index không đúng. các ACE cho mình xin thêm ý kiến. where thì có lúc lấy theo name + active -> search category_id + active-> list bài viết theo thể loại thì nên đánh index riêng từng cột hay gom chung lại như hình trên nhỉ cách bác? p1 -> đánh riêng từng cột p2 -> đánh theo where (name + active) 1 cột , (category_id + active) 1 cột thì cách nào hợp lý hơn cách bác nhỉ ?
nếu chỉ đúng 2 dạng đó thôi thì dùng p2 đi bác, sẽ tốn đĩa hơn cách 1, nhưng sẽ chạy nhanh hơn bên mysql thì em không rõ về các tool hỗ trợ lắm, nhưng bên SQL server thì có tool dạng như Database Engine Tuning Advisor, nó sẽ theo dõi, phân tích và dựa trên độ phức tạp của các truy vấn nặng để gợi ý index thích hợp. Hoặc thử tạo index rồi tra soát lại sql plan của từng dạng query. Bác thử tìm tool tương tự cho mysql xem. 500m rows đối với mysql thì cũng không quá lớn nếu index tốt
chạy thử cái này xem nó báo ntn https://github.com/major/MySQLTuner-perl db bao nhiêu GB Ram bao nhiêu GB
Theo mình không nên clear cache all mà để nó tự expire theo thời gian, khi đó không bị cao tải khi clear cache, ngoài ra có thể áp dụng thêm 1 số tầng cache khác.
Site kiểu này nên dùng nginx cache, rồi mount thư mục cache đó vào ram. Không nên xoá cache all, vì ngay sau khi xoá cache, hoạt động tạo lại cache ngay lúc đó cực kì tốn IO của disk dẫn đến đơ.
Hiện tại mình đang ổn định hơn. trước vì sv (cũ) đang rất ổn định. tự nhiên mình nghịch gì đó ko biết. die ko mở dc =)) sv đó create tầm 3 năm trước rồi nên ko nhớ sau đó tầm tháng trước tạo lại thì CENTOS 7 + PHP 5.6 + MariaDB 10.0 ---> lỗi như kể ở trên hôm qua mình tạo lại CENTOS 7 + PHP 7.1 + MariaDB 10.3 ---> thấy tối qua đến giờ chưa có vẫn đề gì mình chỉ biết cài bằng vpssim và để mặc định. ko biết custom server
