All,
I'm playing around with the parameters of RabbitMQ queues trying to limit growth. I have noticed that the x-max-length parameter works as expected, but when I change to x-max-length bytes, this does not.
See my example below, where we see the argument correctly listed for the queue, but you can see the unbounded growth happening and a memory footprint for the queue of 421MB while I had it set to just 1MB.
Any ides on why this is happening?
Thanks and Regards.
Related
We are running a 2-client 3-server cluster. We keep seeing OOM even as we provide more heap. Below is the heap dump snapshot, any idea why we see so many CacheEvent objects, what is really happening here?
Looking at the source for 'GridSelectorNioSessionImpl', seems it has an unbounded queue that is accumulating WriteRequests. Any idea why are these not being flushed? I was reading about setting messageQueue, even the ignite logs warns about it possibly resulting into an OOM, since its unbounded. But i could not correlate that setting to the queue initialization happening in 'GridSelectorNioSessionImpl'.
TIA
For one of our Projects we have a Hardware Watchdog reset which happens on roughly 0.1% of our devices each day, resulting in many unwanted hardware resets.
We are trying to figure out what causes this Hardware Watchdog reset, but have failed to find anything relevant in our code which would result in this behavior.
We are using the Arduino 2.4.2 Version, we are not sure since when the Problem has bugged our solution since we had other issues which have now mainly been resolved.
Luckily our devices send us their reboot reasons when they reconnect, there we are receiving the following:
ResetReason=Hardware Watchdog;ResetInfo=Fatal exception:4 flag:1 (WDT)
epc1:0x40102329 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000
depc:0x00000000;
We have looked for any thing, when this through the EspStackTraceDecoder we ended up with:
0x40102329: wDev_ProcessFiq at ??:?
A search looking at varies project which have asked similar questions mostly seemed to include a dns query. But not all, so it seems to be a general issue?
What additional information could we extract that might help us identity the issue?
Some Additional Information
Memory is stable and we have ~15-17Kb of free Heap, depending on the mode and the amount of data queued to send / receive queue.
Our side of the code uses yield, delay etc. so the S/W watchdog should always be fed. This also applies to the Async callback code.
Check whether you are doing any wrong memory read. The main reason for HW WDT is that it can trigger the reset if the software (or) cpu is not working anymore.
your CPU might have been stuck while executing some instructions and does't return.
I am working on a block with gnuradio. I have come across a strange performance improvement when i was printing out some huge data on to terminal and the performance degrades without giving a print statement on to terminal.
I infer that while printing out to terminal i am giving gnuradio block an extra processing time for the block to process. This is just my hunch and might not be the exact reason. Kindly correct if this is not correct.
So, is there a way to add a specific amount of processing delay within a block(as what i got during printing out data to terminal) in gnuradio.
Thanks in advance
First of all, the obvious: don't print large amounts of data to a terminal. Terminals aren't meant for that, and your CPU will pretty quickly be the limiting factor, as it tries to render all the text.
I infer that while printing out to terminal i am giving gnuradio block an extra processing time for the block to process. This is just my hunch and might not be the exact reason. Kindly correct if this is not correct.
Printing to terminal is an IO thing to do. That means that the program handling the data (typically, the linux kernel might be handling the PTY data, or it might be directly handed off to the process of your terminal emulator) will set a limit on how it accepts data from the program printing.
Your GNU Radio block's work function is simply blocked, because the resources you're trying to use are limited.
So, can i add a specific amount of processing delay within a block(as what i got during printing out data to terminal) in gnuradio.
Yes, but it doesn't help in any way here.
You're IO bound. Do something that is not printing to terminal – makes a lot of sense, because you can't read that fast, anyway.
RabbitMQ uses a non-negative long (63-bit integer, because non-negative only) called a delivery tag to store how many messages have been sent over a channel. What happens if you send (2^63)+1 messages over a channel?
According to my back-of-napkin calculations, assuming a maximum publish rate of 53,710 messages per second, you would have to be publishing for a total of 7.06 x 10^13 years, which is four orders of magnitude greater than the age of the known universe.
Stated a different way, if we assume that somehow you could publish 3 messages per processor cycle, and that the Intel processor could process 7,000,000,000 messages per second, it would still take nearly 84 years.
Therefore, it is safe to conclude you will run into other issues first. But, if your RabbitMQ server manages to stay up and running that long, you deserve a prize.
But in all seriousness, if this were somehow to happen, I imagine it depends on how Erlang handles integers. This post indicates that Erlang will run out of memory - I don't fully understand how they accomplish that, but maybe then the whole system blows up? Who knows. In c#, the ints simply roll after overflow.
I've read about the frame_max for rabbitMQ, it said frame_max is "Maximum permissible size of a frame (in bytes) to negotiate with clients. Setting to 0 means "unlimited" but will trigger a bug in some QPid clients. Setting a larger value may improve throughput; setting a smaller value may improve latency."
Why the default value is 128 KB. I think in production environment, there is no case in which one wants to have high latency, then why the default value is set so much low. It can be set by default as very high, so as one can have high throughput always. Is there any harm in having high value by default ??? Also, beyond what value is the frame_max behaves as if it is zero i.e. unlimited, which can trigger a bug in QPid clients....
First, you shouldn't need to change this value.
Second, frame_max sets a size of chunks, a unit of multiplexing. It's used to avoid a situation when a single channel can saturate the whole connection. If you publish few big messages, on different AMQP channels, they will be multiplexed. Smaller messages at the same time will be able to move through.
Actually, better concurrency could be achieved by using multiple connections but that's a different story.