[gpfsug-discuss] Potential problems - leaving trace enabled in over-write mode?

[Bryan Banister]

The performance impact can be quite significant depending on what you are tracing.  We even having monitoring that looks for long running traces and the recommended action is to “kill with impunity!!”

I believe IBM recommends never running clusters with continuous tracing.

-Bryan

From: gpfsug-discuss-bounces at spectrumscale.org [mailto:gpfsug-discuss-bounces at spectrumscale.org] On Behalf Of Oesterlin, Robert
Sent: Tuesday, March 07, 2017 2:33 PM
To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Subject: [gpfsug-discuss] Potential problems - leaving trace enabled in over-write mode?

I’m considering enabling trace on all nodes all the time, doing something like this:

mmtracectl --set --trace=def --trace-recycle=global --tracedev-write-mode=overwrite --tracedev-overwrite-buffer-size=256M
mmtracectl --start

My questions are:

- What is the performance penalty of leaving this on 100% of the time on a node?
- Does anyone have any suggestions on automation on stopping trace when a particular event occurs?
- What other issues, if any?


Bob Oesterlin
Sr Principal Storage Engineer, Nuance
507-269-0413



________________________________

Note: This email is for the confidential use of the named addressee(s) only and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you are hereby notified that any review, dissemination or copying of this email is strictly prohibited, and to please notify the sender immediately and destroy this email and any attachments. Email transmission cannot be guaranteed to be secure or error-free. The Company, therefore, does not make any guarantees as to the completeness or accuracy of this email or any attachments. This email is for informational purposes only and does not constitute a recommendation, offer, request or solicitation of any kind to buy, sell, subscribe, redeem or perform any type of transaction of a financial product.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170307/df345b7e/attachment-0002.htm>