There are now a number of nodes that report on node-red and/or system resource usage @BartButenaers has come up with some good stuff. Have a dig around the forum and the Flows site.
The problem with all of the Q'ing nodes is memory. Unless you can afford to drop messages, there will certainly be a limit to how many messages you can hold in a Q. This is made worse of course by the fact that you have to hold all of the code and context variables as well. These factors aren't memory leaks, they are expected operation. Memory leaks would be on top of all that and some nodes do exhibit them, thankfully not many as Node.js seems generally pretty good at handling things.
Just remember that, in Node-RED, a "message" isn't really that at all! It is an allocated chunk of memory that is mostly shared from one node to the next. However, there are a few cases where a message will get cloned. The most common being when you have two wires coming out of the same node output port. Once a specific connected set of nodes has "passed" the message to the last node in the sequence, the message object is destroyed and the memory becomes available to the heap again. If GC kicks in, that heap memory is consolidated and so fully recovered. GC can take an appreciable amount of time BTW and this can add to performance woes in some cases as it stops the main Node.js thread.
Personally, except when developing, I prefer to monitor the device OS as a whole rather than Node-RED separately since that is generally the more important measure. To do that on my home automation system, I run Telegraf with the data going both to InfluxDB for charting views (via Grafana) and to MQTT in case I want to set up alerting in Node-RED. Telegraf also has other alerting outputs.
If you are setting up something for commercial use, I would recommend that you use your normal monitoring tooling and have alerts both for the system and for Node-RED.
The Node-RED nodes, however, can certainly be useful when doing development and testing.