<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:10pt"><div style="font-family: times new roman,new york,times,serif; font-size: 10pt;">Hi Matthew,<br><br>Thanks for investigating this problem! I tried rabbitmq-server from hg tip, but it still crashed when the message consuming rate reached 300 MB/sec. When you ran the test, did you load at least 60 GB messages to 1000 queues? each message is 20 KB in size.<br><br>My machine is RAID-10 with 4 SSD disks: <br>480GB (1%) RAID-10/2 == 4 x 240GB SSD SATA/300<br>Maybe your test machine has only 1 SSD disk so the consuming rate could not reach 300 MB/sec?<br><br>Thanks.<br><br>-alex<br><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Matthew Sackman
<matthew@rabbitmq.com><br><b><span style="font-weight: bold;">To:</span></b> rabbitmq-discuss@lists.rabbitmq.com<br><b><span style="font-weight: bold;">Sent:</span></b> Wed, March 16, 2011 3:49:57 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [rabbitmq-discuss] server crashes with very fast consumers<br></font><br>
Hi Alex,<br><br>On Thu, Mar 10, 2011 at 09:48:08PM -0800, alex chen wrote:<br>> I am testing rabbit server with SSD. The broker process would crash when many <br>> consumers start to consume backed up messages. Because SSD if very fast, the <br>> consuming rate reached more than 200 MB/sec. After several minutes, the broker <br>> process would use all cpu resources (800% on 8 cores) and crash.<br><br>I test all the time on an Intel G2 drive. I've never seen it cause a<br>crash, even in scenarios such as yours. Furthermore, I find it somewhat<br>unlikely that if the server process did die, it didn't spit out any sort<br>of error on its way out. There must be /something/ somewhere that<br>suggests a bit more as to what went wrong, whether it's in syslog, or<br>dmesg, or rabbit's various logs.<br><br>I did however yesterday find and fix a bug where inexplicably a function<br>that normally takes about 0.5s ended up in some very
strange cases<br>taking > 80s. After a lot of head scratching and debugging, I never<br>understood why this variance existed. However, I rewrote the function<br>and it's now much faster all the time. This particular bug has been<br>through QA and is now on default and should be in the next release, thus<br>if you want to try compiling from default and repeating your test, we'd<br>be interested in knowing whether you see any change.<br><br>Matthew<br>_______________________________________________<br>rabbitmq-discuss mailing list<br><a ymailto="mailto:rabbitmq-discuss@lists.rabbitmq.com" href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br></div></div>
</div><br>
</body></html>