Sync viết rất chậm. Ubuntu 10.10, 32 bit, ext4

Tôi đang chạy ActiveMQ trên Macbook Pro chạy Ubuntu 10.10, 32 bit với phân vùng ext4.

Linux iker-laptop 2.6.35-23-generic-pae #40-Ubuntu SMP Wed Nov 17 22:32:51 UTC 2010 i686 GNU/Linux

Nếu tôi kích hoạt tính bền bỉ trong ActiveMQ, hiệu suất sẽ giảm xuống rất nhiều. Tôi đã thử nghiệm điều tương tự trên các máy khác và sự khác biệt là 2 bậc độ lớn.

Có một công cụ với activeMQ để kiểm tra HD, đây là kết quả:

iker@iker-laptop:~/apps/apache-activemq-5.4.1$ java -classpath lib/kahadb-5.4.1.jar org.apache.kahadb.util.DiskBenchmark 

Benchmarking: /home/iker/apps/apache-activemq-5.4.1/disk-benchmark.dat
Writes: 
  146171 writes of size 4096 written in 11.074 seconds.
  13199.477 writes/second.
  51.560455 megs/second.

Sync Writes: 
  197 writes of size 4096 written in 10.006 seconds.
  19.688187 writes/second.
  0.07690698 megs/second.

Reads: 
  5589861 reads of size 4096 read in 10.001 seconds.
  558930.2 writes/second.
  2183.321 megs/second.

Hiệu suất cho Sync Writes là s ** t. Phải có một cái gì đó được định cấu hình sai, nhưng đây là ứng dụng duy nhất mà tôi nhận thấy vấn đề về hiệu suất HD.

hdparm ném các giá trị mong đợi:

iker@iker-laptop:~$ sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   6282 MB in  2.00 seconds = 3141.73 MB/sec
 Timing buffered disk reads:  240 MB in  3.00 seconds =  79.88 MB/sec

Yếu tố giới hạn chính đối với IO đồng bộ không phải là thông lượng của ổ cứng của bạn, mà là thời gian cần thiết khi ghi được phát hành và nó được cam kết vào đĩa. Chỉ số hiệu suất phù hợp nhất cho một ổ cứng trong vấn đề này sẽ là thời gian tìm kiếm của ổ cứng và không phải là thông lượng trong các trường hợp lý tưởng.

Ngoài phần cứng hoạt động chống lại bạn, hạt nhân cũng vậy, tôi đoán bạn có thể thấy một sự cải thiện nhỏ (mặc dù, có lẽ không ở đâu gần với những gì bạn sẽ nhận được khi thực hiện IO async) nếu bạn có thể ion hóa điểm chuẩn (ứng dụng) thành chạy theo lớp lập lịch IO thời gian thực. Theo mặc định, các ứng dụng sẽ được lên lịch theo lớp nỗ lực tốt nhất, có lẽ cũng sẽ thêm vào thời gian chờ viết của bạn. Bạn có thể tự chịu rủi ro khi sử dụng lớp lập lịch thời gian thực vì nó sẽ có tác động xấu đến hiệu suất của các ứng dụng khác khi truy cập đĩa.

Nói chung, tôi thực sự không nghĩ có gì sai trái khủng khiếp với hiệu suất ghi đồng bộ mà bạn đang thấy. IO đồng bộ nói chung sẽ thực hiện khủng khiếp so với IO không đồng bộ.

Là một lưu ý phụ, một google nhanh chóng của activemq và io đồng bộ đã đưa ra như sau :

Vì lý do hiệu suất, bạn có thể muốn truyền phát tin nhắn đến nhà môi giới nhanh nhất có thể ngay cả khi bạn đang sử dụng tin nhắn liên tục

Bộ lập lịch cfq I / O có xu hướng thực hiện khủng khiếp trong các loại thử nghiệm này. Ngoài đề xuất ionice trước đó, bạn có thể muốn thử chuyển sang lịch trình I / O hạn chót (bằng cách khởi động với elevator=deadlinehoặc bằng cách làm for n in /sys/block/sd*/queue/scheduler ; do echo deadline > $n ; doneroot).

Một văn bản đồng bộ phải nhận lại một xác nhận rằng việc ghi đã được cam kết (cho dù cam kết đó là thành công hay lỗi) trước khi nó có thể tự trả lại. Điều này là do thiết kế, và vốn đã làm cho việc ghi đồng bộ chậm hơn nhiều do thời gian trễ cao liên quan đến một đĩa kim loại quay (trên bộ đệm ram đĩa không tính).

Ghi không đồng bộ thường được ghi vào RAM và HĐH xử lý cam kết nó vào đĩa sau (sau này thường chỉ là vài giây hoặc ít hơn (tôi tin rằng ZFS là 5x / giây hoặc cứ sau 5 giây)). Thời gian tìm kiếm đĩa được đo bằng ms trong khi thời gian tìm kiếm RAM được đo bằng ns. Đó là sự khác biệt 1000 lần.

Sử dụng ghi đồng bộ khi hoàn toàn quan trọng rằng dữ liệu được lưu trữ vĩnh viễn trước khi tiếp tục và độ trễ 1 giây khi mất điện có thể xảy ra là không thể chấp nhận được.

Sử dụng ghi không đồng bộ ở tất cả các lần khác.

Lý do có thể xảy ra nhất mà bạn đang thấy sự cố hiệu suất này là do bạn đang sử dụng "-o sync" với hệ thống tệp được ghi nhật ký và các rào cản được bật (vốn là mặc định cho ext4).

Đây là nơi quyết định làm gì để cải thiện nó trở nên rất khó khăn.

Nó chủ yếu tập trung vào mức độ bạn tin tưởng vào phần cứng của bạn.

Từ mount (8): "Ghi các rào cản thực thi thứ tự ghi đĩa trên đĩa đúng cách, làm cho bộ đệm ghi dễ bay hơi an toàn khi sử dụng, ở một số hình phạt hiệu năng. Hệ thống tệp ext3 không bật các rào cản ghi theo mặc định. đĩa của bạn được hỗ trợ bằng cách này hay cách khác. Nếu không, bạn có nguy cơ bị hỏng hệ thống tập tin trong trường hợp mất điện. "

Vì vậy, chấp nhận hiệu suất "-o sync" thực tế là ảm đạm, hoặc mua bộ nhớ cache dựa trên pin cho bộ điều khiển của bạn và các đĩa SAS thực sự tốt, sau đó tắt các rào cản bằng cách sử dụng "-o sync, nobarrier".

Nếu những gì bạn hiện đang sử dụng là một phụ trợ lưu trữ FC hoặc iSCSI cấp doanh nghiệp phù hợp, thì tôi đoán bạn cũng an toàn để thực hiện việc sau.

Nói chung, ActiveMQ 5.4 sử dụng phụ trợ lưu trữ KahaDB theo mặc định và một cái cũng có nhật ký giao dịch riêng, do đó, thậm chí có thể tắt nhật ký ở cấp hệ thống tệp có thể hoạt động cho bạn, nhưng sau đó hãy chắc chắn rằng bạn sử dụng "enableJournalDiskSyncs" tùy chọn cho phần phụ trợ và có lẽ bạn cũng muốn đặt nó trên một thiết bị khối riêng nếu bạn chưa có.

(xem http://activemq.apache.org/kahadb.html để biết thêm)

Viết đồng bộ là chậm, đó là lý do tại sao chúng tôi đệm tất cả mọi thứ. Hãy xem IOPS trên Wikipedia và bạn sẽ thấy một ổ cứng 7.200 vòng / phút thông thường có 75-100 IOPS. Bây giờ hãy xem thông số kỹ thuật của Macbook Pro và nó có ổ cứng 5.400 vòng / phút. Đó là hiệu suất 75% ở mức tốt nhất vì vậy bạn đang xem xét 50-75 IOPS ở mức tốt nhất cho máy tính xách tay.

Một MQ có thể viết một sổ cái dữ liệu và một sổ cái kế toán, đưa bạn đến 20 IOPS mà bạn đang thấy trong điểm chuẩn ActiveMQ.

Bạn có hai tùy chọn, kiểm tra trên tmpfs , tức là hệ thống tệp trong bộ nhớ hoặc sử dụng ổ SSD. Thông thường các máy chủ sử dụng ghi đồng bộ sẽ có một mảng RAID / SCSI đáng kể với 15.000 vòng / phút. Đĩa phụ được thêm vào mảng để cải thiện hiệu suất, không tăng dung lượng.

Trên máy ảo được lưu trữ (trong VirtualBox) chạy máy chủ Ubuntu 11.10 64 bit cũng sử dụng ext4, chúng tôi đã thu được các kết quả sau:

Sync Writes:
 288 writes of size 4096 written in 10.034 seconds.
 28.702412 writes/second.
 0.112118796 megs/second.

Trên máy chủ vật lý đang chạy Redhat 5.7 64 bit bằng cách sử dụng ext3, đã thu được các kết quả sau:

Sync Writes:
  54987 writes of size 4096 written in 10.001 seconds.
  5498.1504 writes/second.
  21.47715 megs/second.

Tôi tự hỏi nếu OP cũng chạy nó trong VM hay nếu có vấn đề giữa ext3 và ext4. Tôi đánh giá cao rằng có thể có một sự khác biệt giữa môi trường được lưu trữ và không được lưu trữ, tuy nhiên không mong đợi một sự khác biệt lớn như vậy.

Sử dụng kích thước khối lớn hơn. Bạn có thể nhầm lẫn IO đồng bộ / async với IO trực tiếp / được đệm không?