Xin chào anh! Em đọc qua loạt bài về PostgreSQL của anh em học được rất nhiều, em cám ơn rất nhiều về những chia sẻ ạ. Em hiện có đang quản trị 1 server DB PostgreSQL nhưng đang gặp phải vấn đề về CPU hệ thống đang khá cao tầm 30-50% CPU lúc cao điểm. Do DB trước đó chưa dùng đến index, giờ em đã sử dụng tạo index ở những table em nắm chắc rồi thì tải giảm xuống cũng khá nhiều rồi còn tầm 15-30% nhưng em muốn cải thiện thêm nữa, thì làm sao để có thể ghi log hay theo dõi được các query sử dụng CPU cao vậy anh, theo dõi process thì không kịp lấy PID để xem query chạy là gì thì nó mất tiêu rồi. Xin anh chỉ giúp em với ạ
Hi b, thường quá trình read/write data không ảnh hưởng nhiều đến CPU mà chủ yếu là I/O. Việc tăng CPU ở đây có 3 khả năng, 1 là query loằng ngoằng nên việc lên plan sẽ tốn CPU, 2 là vđề query parallel execution trên nhiều processor khác nhau, 3 là do có locking.
Bạn có thể thử query này SELECT * FROM pg_stat_activity; để check. Trong đó có khá nhiều thông số có ích như query statement, time, PID...
Ngoài ra nếu log long time query thì có thể thực hiện ALTER DATABASE test SET log_min_duration_statement = 5000;, đơn vị là ms. Nó sẽ log ra những query có execution time >= 5000.
@datbv Dạ cám ơn anh. Em có Explain đánh giá trước và sau khi dùng index cost giảm khá nhiều nên 1 phần là em chưa dùng tốt index. Ở vấn đề 2, dạ đúng là có các query parallel execution trên nhiều processor. Nhưng em chưa hiểu lắm, mong anh nói rõ hơn chổ này chút ạ, do query em chưa tốt nên postgres mới cần xử lý parallel trên nhiều worker để xử lý cho querry đó. Và càng nhiều querry như thế nên tải CPU server mới cao như thế phải không ạ?.
@datbv Việc theo dõi qua pg_stat_activity, em chỉ áp dụng được khi hệ thống đang có vấn đề lock, số lượng transaction treo lớn. Còn trong cần tìm query dẫn đến CPU cao em chưa hiểu để áp dụng được ạ. Em có đặt log duration query với 1000ms và kèm theo auto_explain rồi ạ, nhưng k có nhiều ạ.
@mtruyenvl yep đúng như bạn nói. Mình là dev nên theo kinh nghiệm và lượng kiến thức mình có chỉ dừng lại ở mức này. Bạn có thể tham khảo thêm các DBA xem thế nào.
CPU cao chưa hẳn đã là xấu, vì như vậy là tận dụng được hết resource đang có. Bạn để postgres trên server riêng hay chung server với các application khác? Nếu CPU stress > 90% trong thời gian dài mới cần lo. Còn như bạn nói chỉ ~ 50% khi peak thì không có gì phải lo, nó đang tận dụng đc tối đa resource. Đấy là ý kiến cá nhân của mình.
Hello anh,
Trong bài viết JSK8-17 a chia sẻ về OCP JP 11. Anh có thể chia sẻ thêm về tài liệu cũng như kinh nghiệm của a lúc thi cert này được không ạ? Em có xin connect trên Linkedin nhé
Chào anh!
Thấy anh cũng có nhiều bài viết hay chia sẻ về Java.
Bên em muốn liên hệ hợp tác cùng anh tham gia dự án đào tạo về Java (parttime) và chia sẻ các bài viết. Nếu anh quan tâm, anh có thể cho em xin thông tin email để em tiện liên hệ ạ. Hoặc anh có thể gửi thông tin qua mail: manpham@techmaster.vn hoặc zalo: 0963023185 để em tiện liên hệ với ạ. Em cảm ơn!
@datbv à dạ vâng ạ, rất vui được kết nối với anh. Bên em đang cần bổ sung thêm các giảng viên cộng tác ạ, nếu anh quan tâm thêm về mảng này thì có thể cho Techmaster có cơ hội được làm việc cùng anh.
nhưng mình có thử bật tắt open-in-view mà không giải quyết dc vấn đề,
thực ra là mình test thử local, việc bật tắt open-in-view những vẫn dùng LAZY load được, bạn có thể support giúp mình được không? cho mình cách liên lạc để tiện trao đổi được không bạn, mình thật sự cần giúp đỡ. cảm ơn b.
Tại sao nên sử dụng Redis để lưu user profiles, friend lists trong Social media
Em đọc trên mạng thì thấy họ có đưa ra use case như vậy
Đây là một vài lý do em đang hiểu
Chắc chắn nhắc đến Redis thì người ta nghĩ ngay đến xử lý nhanh rồi, tăng tính trải nghiệm của user
Bởi vì thông tin của user ví dụ như mail, sdt, name, danh sách bạn bè ít bị thay đổi, và có thể lấy ra thường xuyên, (ví dụ như ở page nào hay làm hành động gì cũng cần những thông tin user, nên đây cũng là lý do chính)
Em thì đang hiểu như vậy, mong các Anh/Chị trong nhóm cho em thêm một vài góc nhìn mới với ạ
Chào anh , em hiện có 1 dự án triển khai cũng khoảng 3 năm , lúc trước số lượng record ít nhưng giờ ngày càng to do dự án ngày càng mở rộng. Cụ thể em làm về nhận diện biển số xe, trung bình mỗi ngày có hơn 2 triệu record . Một số giờ cao điểm xe đông thì số lượng record sẽ tăng . Dạo gần đây em bị một hiện tượng là postgres bắt đầu lưu cực kì chậm, hoặc là get dữ liệu cũng cực kì chậm đột xuất . Có khi nó làm dữ liệu của em lưu trễ cả ngày , tốc độ lưu trữ cũng chậm hơn rất nhiều so với bình thường. Dữ liệu em có cache trên rabbitmq , sử dụng worker để gọi xuống . Em check I/O dùng rất ít so với ổ đĩa NVME ( không đến 5Mb) . CPU server của em cũng có hơn 64 core nhưng nó chỉ dùng có 4-5 core trong đó. RAM thì em check nó dùng đến hơn 300Gb Ram ở những lúc bị chậm như vậy. Anh có kinh nghiệm có thể cho em xin 1 ít để tìm cách gỡ hoặc tối ưu với anh . Cảm ơn anh nhiều
Bác có viết bài trên blog nào không? Em muốn theo dõi thêm.
Mình hiện tại viết trên blog này thôi kiếm fame trước đã
Xin chào anh! Em đọc qua loạt bài về PostgreSQL của anh em học được rất nhiều, em cám ơn rất nhiều về những chia sẻ ạ. Em hiện có đang quản trị 1 server DB PostgreSQL nhưng đang gặp phải vấn đề về CPU hệ thống đang khá cao tầm 30-50% CPU lúc cao điểm. Do DB trước đó chưa dùng đến index, giờ em đã sử dụng tạo index ở những table em nắm chắc rồi thì tải giảm xuống cũng khá nhiều rồi còn tầm 15-30% nhưng em muốn cải thiện thêm nữa, thì làm sao để có thể ghi log hay theo dõi được các query sử dụng CPU cao vậy anh, theo dõi process thì không kịp lấy PID để xem query chạy là gì thì nó mất tiêu rồi. Xin anh chỉ giúp em với ạ
Hi b, thường quá trình read/write data không ảnh hưởng nhiều đến CPU mà chủ yếu là I/O. Việc tăng CPU ở đây có 3 khả năng, 1 là query loằng ngoằng nên việc lên plan sẽ tốn CPU, 2 là vđề query parallel execution trên nhiều processor khác nhau, 3 là do có locking.
Bạn có thể thử query này
SELECT * FROM pg_stat_activity;để check. Trong đó có khá nhiều thông số có ích như query statement, time, PID...Ngoài ra nếu log long time query thì có thể thực hiện
ALTER DATABASE test SET log_min_duration_statement = 5000;, đơn vị là ms. Nó sẽ log ra những query có execution time >= 5000.Hy vọng phần nào trả lời được câu hỏi của bạn.
@datbv Dạ cám ơn anh. Em có Explain đánh giá trước và sau khi dùng index cost giảm khá nhiều nên 1 phần là em chưa dùng tốt index. Ở vấn đề 2, dạ đúng là có các query parallel execution trên nhiều processor. Nhưng em chưa hiểu lắm, mong anh nói rõ hơn chổ này chút ạ, do query em chưa tốt nên postgres mới cần xử lý parallel trên nhiều worker để xử lý cho querry đó. Và càng nhiều querry như thế nên tải CPU server mới cao như thế phải không ạ?.
@datbv Việc theo dõi qua pg_stat_activity, em chỉ áp dụng được khi hệ thống đang có vấn đề lock, số lượng transaction treo lớn. Còn trong cần tìm query dẫn đến CPU cao em chưa hiểu để áp dụng được ạ. Em có đặt log duration query với 1000ms và kèm theo auto_explain rồi ạ, nhưng k có nhiều ạ.
@mtruyenvl yep đúng như bạn nói. Mình là dev nên theo kinh nghiệm và lượng kiến thức mình có chỉ dừng lại ở mức này. Bạn có thể tham khảo thêm các DBA xem thế nào.
CPU cao chưa hẳn đã là xấu, vì như vậy là tận dụng được hết resource đang có. Bạn để postgres trên server riêng hay chung server với các application khác? Nếu CPU stress > 90% trong thời gian dài mới cần lo. Còn như bạn nói chỉ ~ 50% khi peak thì không có gì phải lo, nó đang tận dụng đc tối đa resource. Đấy là ý kiến cá nhân của mình.
@datbv Dạ vâng cám ơn anh nhiều ạ.
upvote chưa :v gửi a fb của e nhé a add
@datbv kết bạn với em đi anh.
sao anh không tạo thành 1 blog chia sẻ nhiều hơn, mà làm sao để thành trùm được anh, chia sẻ mánh khóe đi anh.
A k phải trùm nên a k biết gì đâu em ơi :-s
@datbv anh làm java à.
@tranphong19951999 đúng r em
@datbv lương trên 5k chưa anh.Nói để cho em có động lực cày anh.
@tranphong19951999 5k/năm thì chắc là được em ơi
Hello anh, Trong bài viết JSK8-17 a chia sẻ về OCP JP 11. Anh có thể chia sẻ thêm về tài liệu cũng như kinh nghiệm của a lúc thi cert này được không ạ? Em có xin connect trên Linkedin nhé
Chào anh! Thấy anh cũng có nhiều bài viết hay chia sẻ về Java. Bên em muốn liên hệ hợp tác cùng anh tham gia dự án đào tạo về Java (parttime) và chia sẻ các bài viết. Nếu anh quan tâm, anh có thể cho em xin thông tin email để em tiện liên hệ ạ. Hoặc anh có thể gửi thông tin qua mail: manpham@techmaster.vn hoặc zalo: 0963023185 để em tiện liên hệ với ạ. Em cảm ơn!
hi Mẫn, em bên Techmaster à
@datbv Dạ đúng rồi anh ạ. Anh có biết đến bên em ạ?
@manpt ừ a có làm việc với a Cường mấy lần rồi
@datbv à dạ vâng ạ, rất vui được kết nối với anh. Bên em đang cần bổ sung thêm các giảng viên cộng tác ạ, nếu anh quan tâm thêm về mảng này thì có thể cho Techmaster có cơ hội được làm việc cùng anh.
viết về cách thiết kế hệ thống chịu tải cao đi bác.
hi em, mail a đây nhé: datbv.other@gmail.com
Hi anh, Anh cho em xin tips ôn OCP 11 với ạ
Chào anh, anh cho em xin tips thi OCP 11 được không ạ. Mong được anh giúp đỡ.
Anh từng làm tại Fortna đúng không ạ?
Em đọc series về Apache Kafka thấy bác chia sẻ chi tiết, đọc cuốn quá, bác có dùng LinkedIn hay Fb gì không, nếu có thì cho em xin connect với ạ 🤩
Hi b, mình gặp lỗi tương tự như trong bài post này https://viblo.asia/p/hikari-connection-is-not-available-request-timeout-after-30000ms-PAoJeZbDL1j
nhưng mình có thử bật tắt open-in-view mà không giải quyết dc vấn đề, thực ra là mình test thử local, việc bật tắt open-in-view những vẫn dùng LAZY load được, bạn có thể support giúp mình được không? cho mình cách liên lạc để tiện trao đổi được không bạn, mình thật sự cần giúp đỡ. cảm ơn b.
Tại sao nên sử dụng Redis để lưu user profiles, friend lists trong Social media
Em đọc trên mạng thì thấy họ có đưa ra use case như vậy Đây là một vài lý do em đang hiểu Chắc chắn nhắc đến Redis thì người ta nghĩ ngay đến xử lý nhanh rồi, tăng tính trải nghiệm của user Bởi vì thông tin của user ví dụ như mail, sdt, name, danh sách bạn bè ít bị thay đổi, và có thể lấy ra thường xuyên, (ví dụ như ở page nào hay làm hành động gì cũng cần những thông tin user, nên đây cũng là lý do chính) Em thì đang hiểu như vậy, mong các Anh/Chị trong nhóm cho em thêm một vài góc nhìn mới với ạ
Chào anh , em hiện có 1 dự án triển khai cũng khoảng 3 năm , lúc trước số lượng record ít nhưng giờ ngày càng to do dự án ngày càng mở rộng. Cụ thể em làm về nhận diện biển số xe, trung bình mỗi ngày có hơn 2 triệu record . Một số giờ cao điểm xe đông thì số lượng record sẽ tăng . Dạo gần đây em bị một hiện tượng là postgres bắt đầu lưu cực kì chậm, hoặc là get dữ liệu cũng cực kì chậm đột xuất . Có khi nó làm dữ liệu của em lưu trễ cả ngày , tốc độ lưu trữ cũng chậm hơn rất nhiều so với bình thường. Dữ liệu em có cache trên rabbitmq , sử dụng worker để gọi xuống . Em check I/O dùng rất ít so với ổ đĩa NVME ( không đến 5Mb) . CPU server của em cũng có hơn 64 core nhưng nó chỉ dùng có 4-5 core trong đó. RAM thì em check nó dùng đến hơn 300Gb Ram ở những lúc bị chậm như vậy. Anh có kinh nghiệm có thể cho em xin 1 ít để tìm cách gỡ hoặc tối ưu với anh . Cảm ơn anh nhiều