Nên dùng CSDL nào khi chạy multithread Python

50 thread nhưng thực chất CPU ví dụ laptop mình chỉ có 8 lõi, 16 luồng, tức là max 16 luồng, vậy 50 luồng lúc ấy CPU sẽ lập lịch phân bổ, vì vậy tổng thời gian tính toán chưa chắc nhanh bằng setup 16 luồng, hơn nữa python thực chất 50 luồng nhưng chỉ chạy có 1 luồng ở 1 thời điểm vì vậy nên người ta mới nói python chậm ở điểm đó, nên 50 luồng ko có tác dụng gì mấy.

3 Likes

e dùng thử mysql rồi nhưng nó báo lỗi đại loại là request nhiều quá nên timeout hay quá tải gì á. em cài xampp để chạy mysql :smile:

thanka để e tìm hiểu mongo db xem

1 Like

cpu hiện tại là max 16 luồng ạ. e đang dùng vps 8 core 18gb ram mà k biết nó bao nhiều luồng, nhưng taskmanager check chỉ 40-60% cpu

vậy bác setup 16 luồng là max, setup cao hơn ko giải quyết dc gì, kiểu gì, việc gì cũng làm dc 1 ít, nhưng ko xong dc cái gì

2 Likes

Còn phụ thuộc vào task dạng nào. CPU bound task như for loop đến 1 tỉ, thì cần CPU thực hiện nhiều nên set = số luồng của CPU là tốt nhất. Nhưng task IO bound như call API, FileIO thì số luồng có thể lớn hơn rất nhiều vì đa số CPU sẽ chơi khi đợi IO. Tuy nhiên IO bound sẽ vẫn có giới hạn về nhiều mặt như: số lượng IO vào disk, memory, context switch.

python đơn luồng nhưng vẫn xử lý đồng thời cho IO task https://docs.python.org/3/library/threading.html

1 Like

cái này e ko rõ nghe đâu, cái công việc i/o ở python là dùng lib bên thứ 3 nên ko được tốt và hiệu quả

2 Likes

đúng là nhiều luồng nhưng sức mạnh của cpu phải đáp ứng được thì mới thấy hiệu quả, e thử test tăng thêm luồng thì thực sự mỗi luồng chạy rất chậm, mặc dù check taskmanager chỉ chiếm khoảng 6-70% cpu . :laughing:

2 Likes

Giờ mới nhận ra à? Nếu không thế thì người ta cần quái gì phải có những server có nhiều core và nhiều U, hoặc ta cứ nghe thông số Xeon x1234, Xeon e4321, blah blah chi mà rắc rối. Nói chung là ngoài CPU thì còn có các tài nguyên khác của máy tính nữa (RAM, ổ cứng, PCI, mainboard), rồi kèm với giải thuật được viết tốt, chương trình dùng tài nguyên hợp lý => hiệu suất cao.

3 Likes

e đang thuê setup dedicated server cấu hình
CPU: 2 x Intel® Xeon® E5-2680 v4
35M Cache, 2.40 GHz up to 3.30 GHz
(Total: 28 cores, 56 threads)

  • RAM: 64GB DDR4

  • Disk: 2 x 600GB SAS 10K

a thấy cấu hình này là thấp hay trung bình nhỉ

bạn đang sử dụng server đó cho mục đích gì, data mỗi ngày cả triệu record từ đâu ra, insert vào database để làm gì? đây là bussiness để kiếm tiền hay là bài tập, hay chỉ đơn giản là test chơi?

3 Likes

phải thuê cả dedicated sv thì tất nhiên là e kiếm tiền rồi ak.

e đang dùng vps, script của e logic là bắt đầu sẽ chạy 10 thread, mỗi thread này xử lí khoảng 1-10k dòng dữ liệu là done, vì thế e for loop 10 thread đó rồi x100 thread con ( tổng 10x100 = 1000 thread ) và chạy ổn ở thời điểm bt.

nhưng khi cao điểm, dữ liệu đẩy về quá nhiều thì 10 thread lại hơi lâu nên e muốn thuê SV mạnh hơn để chạy khoảng 50 thread x 100 thread con = 5000 thread ý ak.

code e đã tối ưu, nên vấn đề chỉ là sức mạnh của server hehe

đẩy về từ đâu, http, tcp hay là từ nguồn nào, giao thức nhận input là gì
và khi nhận data, bạn chỉ insert và không làm gì khác?
vậy khi insert được 1 cục data như thế thì cục đó được sử dụng như nào?

dựa vào đâu mà biết code đã tối ưu
ngay từ lúc thấy bạn chọn sqlite làm database chỉ vì có thể mang 1 file data đi là đã thấy sai rồi

từ đầu tới cuối mình không thấy bạn nhắc đến những vấn đề ở trên, trong khi để tư vấn được giải pháp thì cần phải hiểu những vấn đề đó thì mới ra được giải pháp được
và chốt là bạn đã nói bạn cần “server mạnh hơn” thì còn gì nữa đâu mà tư vấn

5 Likes

Giờ thử dump hết tất cả dữ liệu trong vòng 1 ngày xem nó bao nhiêu dòng cụ thể. Kích thước của nó bao nhiêu GB?

Liệu có thể xác định được maximum số dòng cần không? Nếu xác định được, ta tính được kích thước của khối đó.

Thử dùng dùng hết 50GB của server đang có (dành cho tài nguyên còn lại 14GB RAM là đủ) nạp hết dữ liệu thu thập được lên RAM. Nếu không rành việc lập trình kiểu cấp phát động kiểu ngôn ngữ C thì dùng mấy cái như Redis, Memcached để hỗ trợ.

Dữ liệu chứa lên RAM là những mảng/ chuỗi dạng như JSON chứa dữ liệu. Đến giờ thấp điểm (nếu server có phục vụ việc khác) hoặc chỉ định thấp điểm thì mới lấy cái trong RAM đó trút vào cơ sở dữ liệu.

Hiện nay, loại ổ cứng tốc độ cao nhất đọc/ ghi khoảng 4GB/ giây, trong khi đó, nếu RAM đủ tiêu chuẩn, loại tốc độ cao nhất khoảng 25GB/ giây.

Mà còn một giới hạn đó là nếu dữ liệu thu thập qua mạng, thì rõ ràng là không cách nào để 1 giây nó lấy được nhiều hơn 1 Gigabit (cạc mạng hiện tại chỉ hỗ trợ đến đó), tức là không có chuyện lấy được hơn 125 Mega Bytes mỗi giây cả. Cho nên, đừng mong rằng có thể tải về hàng GB được, dù RAM, ổ cứng, CPU đang thừa công suất cho việc xử lý hàng ngàn dòng text/ giây. Để giải quyết giới hạn này chắc là phải gắn nhiều cạc mạng, và cái này thì mình cũng không rõ làm sao để ghép băng thông :smiley:

Mà đọc qua có vẻ đang không rõ là thuê VPS hay là Dedicated server (là con server phần cứng có thể bê đi được và khi shutdown thì phải nhờ người ta bật lại). Hai cái này khác xa nhau nhiều lắm nhé, dù có đơn vị quảng cáo VPS nhanh và quản lý dễ nhưng server ảo thì không cách chi bằng server vật lý được. Nếu ai đó lý luận VPS tốt hơn, mạnh hơn, mình sẽ hỏi: tại sao người ta không dùng server ảo chứa server vật lý?

5 Likes

Uhm, server này của cậu là quái vật rồi :sweat_smile:

Tớ nghĩ cậu nên ngừng suy nghĩ nhiều thread = nhanh hơn, nhất là khi cậu chỉ có 1 máy. CPU sẽ là bottleneck của cậu, và cậu cũng vẫn đang có bottleneck là database.
Ngoài ra, theo mô tả của cậu, có vẻ như cậu đang tạo batch job (sửa lại tớ nếu tớ đoán sai nha :sweat_smile: ) => cậu càng không cần quan tâm tới việc optimize để batch job chạy nhanh hơn.
Tớ thậm chí nghĩ cậu không cần tới nhiều hơn 2 thread. Trong code của cậu có ghi job này để ghi log, mà công việc này vốn có thể thực hiện bất đồng bộ, nên cậu hoàn toàn có thể đặt 1 Message queue trước worker của cậu để lần lượt insert dữ liệu vào log table. Thực tế, 2 threads hoàn toàn có thể xử lý 115 QPS (10M transaction/ngày) mà không gặp vấn đề gì, nếu cậu sử dụng MySQL (thậm chí chưa nói tới NoSQL) thay vì sqlite (tớ đã từng thực hiện performance test setup tương tự trên production, với DB server spec yếu hơn của cậu, mà không phải bare metal server :sweat_smile: ).
Cậu cũng hoàn toàn có thể tái sử dụng connection, thay vì mở và đóng connection liên tục như trong code cậu show ở post #1 (FYI, mở connection là thao tác rất đắt đỏ).

Vậy nên, “sức mạnh server” của cậu không phải vấn đề đâu :sweat_smile:

4 Likes

thank mn, tổng hợp từ các ý kiến của mn e đang viết lại vài chỗ cho tối ưu hơn và thuê 1 con sv trâu hơn.
hiện tại chạy nhanh hơn hơn khoảng 3 lần trước khi e đăng câu hỏi, cũng khá ổn. kiếm đc bèo bọt 10-15tr/ngày mà mệt với n mấy hôm nay hihi

2 Likes

2 posts were merged into an existing topic: Topic lưu trữ các post off-topic - version 3

83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?