On Thu, 2011-06-30 at 06:14 -0600, Emir Ibrahimbegovic wrote: > How do I calculate queue capacity if my queue has configured with the > following parameters -file-size=3072 --file-count=32? > > Thank you, > E
The size of the file store for each queue is easy to calculate. The file-size parameter is the number of 64k blocks, while the file-count parameter is the number of files. Each file has a size of: 65536 * 3072 = 201326592 = approx. 200M Having 32 such files gives a per-queue store size of: 201326592 * 32 = 6442450944 = approx. 6G Translating this into messages is not so easy, as each message has a header which is variable and is stored in a space in the store which is rounded up to the nearest 128-byte boundary. In addition, if transactions are used, then the flushing which takes place during commits will flush up to 3 128-byte blocks to reach the nearest 512-byte boundary before writing, which can leave the store files sparse. The store files operate as a circular buffer. If at any point, the store is asked to store a message which will take the amount of free space after it is written to less than 20% (ie it is more than 80% full) then the enqueue will be rejected with an enqueue capacity threshold error. As a very rough rule of thumb, it is a good idea to make the store twice the size of the message content you expect to accumulate when no transactions are in use. ie Find the worst-case for message size and how many messages you expect to accumulate, then double it. If transactions are in use, then this gets more complex as the transaction size plays a big role in the store usage pattern. On a separate issue, making the store really big is easy to do, but it will cost you in the following ways: 1. Each time a persistent queue is declared, the store will create and format these files for that queue. The time taken to declare the queue will depend on how fast your disk system can write out (in your case) 6G of files, and this will appear to you as a delay/holdup in declaring the queue. 2. If you should need to recover (ie starting up with full recovery), there can be a substantial delay as the store reads _all_ your queues and analyzes the files and records in those files. If you have a large number of persistent queues with large stores, you may need to increase the wait time if you use the daemon mode for starting the broker (ie using --daemon). If you use Qmf to create queues, you can set the size of the store files on a per-queue bases. Otherwise the broker parameters --jfile-size and --num-jfiles will set the default size for all stores. I hope that helps. Kim --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
