Pengzna opened a new pull request, #12088:
URL: https://github.com/apache/iotdb/pull/12088
## Description
We have recently investigated some GC options. Based on the product
scenarios of IoTDB, we have selected some general JVM GC options. For options
that are completely beneficial and harmless, we plan to directly add them to
the default startup options of IoTDB; For options that are only beneficial in
some specific scenarios, we plan to add them to default startup options through
comments and explain their usage. Please review~
1. Directly added options:
**-Xss512k**： This option is intended to optimize the memory occupied
bythreads. The default value is 1m. Based on our research and actual usage
scenarios of iotdb, we suggest that the thread stack size of 512k is
sufficient. Many online business systems also set up in this way.
**-XX:+UnlockDiagnosticVMOptions**： Used to unlock some diagnostic JVM
options, such as -XX:GuaranteedSafepointInterval. This option itself has no
direct impact on performance.
**-XX:+UseCountedLoopSafepoints**： Prevent the delay in entering the
safepoint caused by large bounded loops from causing the GC STW time to be too
long.
**-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=1000**： These two options
will monitor the waiting time of the jvm threads in safepoint. If it exceeds
1000ms, the state of the corresponding threads will be printed to the log to
help us troubleshoot the problem of too long safepoint stw time.
**-XX:GuaranteedSafepointInterval=0**： Disable scheduled safepoint tasks. In
high concurrency scenarios of IoTDB, it is not necessary to enter the safepoint
regularly, but may cause additional overhead.
**-XX:-UseBiasedLocking**： Disable biased lock. In high concurrency
scenarios of IoTDB, biased locks are basically useless and have negative
effects with safepoints. In fact, biased locking has been disabled by default
since JDK15.
**-XX:+UseAdaptiveSizePolicy**： Turn on GC adaptive tuning（Ergonomics）
2. Added through comments:
**-XX:+ParallelRefProcEnabled**： Turn on parallel processing of Reference
objects in GC process. This option may help if particularly long reference
processing times are observed in the GC logs. Please note: because this option
consumes thread resources, it may have an impact on application's throughput.
**CPU_PROCESSOR_NUM=$(nproc)
-XX:ParallelGCThreads=${CPU_PROCESSOR_NUM}**：Set the processing thread of
parallel gc to the number of machine CPU cores. Please note: When the GC time
is too long, if there are remaining CPU resources, you can try to increase this
option. Although this will occupy application thread resources, but because the
GC
becomes faster, it will have minor impact on the application. If CPU
resources have reached a bottleneck, increasing this option may make
application slower even if it makes the GC faster.
**-XX:+AlwaysPreTouch**： Force the operating system to allocate all memory
in advance when the JVM starts, so that all heap areas are allocated physical
memory. It can reduce the overhead caused by memory allocation, page fault
interrupts, etc. during JVM operation. In some large memory scenarios, we have
observed about 10% improvement in throughput with this option. Please note: The
use of this option will cause the JVM to start slower. At the same time, the
physical memory usage of iotdb will reach the maximum heap memory immediately
after JVM startup, which may reduce memory utilization and trigger OOM killer
when memory is tight.
**Note：In addition to linux, we have also adapted scripts to windows and
macOS**
<!--
In each section, please describe design decisions made, including:
- Choice of algorithms
- Behavioral aspects. What configuration values are acceptable? How are
corner cases and error
conditions handled, such as when there are insufficient resources?
- Class organization and design (how the logic is split between classes,
inheritance, composition,
design patterns)
- Method organization and design (how the logic is split between methods,
parameters and return types)
- Naming (class, method, API, configuration, HTTP endpoint, names of
emitted metrics)
-->
<!-- It's good to describe an alternative design (or mention an alternative
name) for every design
(or naming) decision point and compare the alternatives with the designs
that you've implemented
(or the names you've chosen) to highlight the advantages of the chosen
designs and names. -->
<!-- If there was a discussion of the design of the feature implemented in
this PR elsewhere
(e. g. a "Proposal" issue, any other issue, or a thread in the development
mailing list),
link to that discussion from this PR description and explain what have
changed in your final design
compared to your original proposal or the consensus version in the end of
the discussion.
If something hasn't changed since the original discussion, you can omit a
detailed discussion of
those aspects of the design here, perhaps apart from brief mentioning for
the sake of readability
of this PR description. -->
<!-- Some of the aspects mentioned above may be omitted for simple and small
changes. -->
<hr>
This PR has:
- [x] been self-reviewed.
- [ ] concurrent read
- [ ] concurrent write
- [ ] concurrent read and write
- [x] added documentation for new or modified features or behaviors.
- [ ] added Javadocs for most classes and all non-trivial methods.
- [ ] added or updated version, __license__, or notice information
- [x] added comments explaining the "why" and the intent of the code
wherever would not be obvious
for an unfamiliar reader.
- [ ] added unit tests or modified existing tests to cover new code paths,
ensuring the threshold
for code coverage.
- [ ] added integration tests.
- [ ] been tested in a test IoTDB cluster.
<!-- Check the items by putting "x" in the brackets for the done things. Not
all of these items
apply to every PR. Remove the items which are not done or not relevant to
the PR. None of the items
from the checklist above are strictly necessary, but it would be very
helpful if you at least
self-review the PR. -->
<hr>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
