Denis,
Yes, Ignite page size should be *greater or equal* than OS page cache
size and SSD page size. I mentioned it in advice list:
page size of Ignite shouldn't be less than SSD page size
Page size of Ignite shouldn't be less than OS page size
Sorry for vague wording.
We should fix this in documentation.
Best Regards,
Ivan Rakov
On 14.09.2017 3:46, Denis Magda wrote:
Ivan,
Documented:
https://apacheignite.readme.io/v2.1/docs/durable-memory-tuning
<https://apacheignite.readme.io/v2.1/docs/durable-memory-tuning>
However, I’m a bit confused with you 6. point regarding the page size calculation.
Should Ignite page size be always less than the SSD’s page size and OS page cache
size? Or it can be equal? For instance if the OS page cache size is 4 KB what should
be Ignite’s page size? That’s the section about this:
https://apacheignite.readme.io/v2.1/docs/durable-memory-tuning#section-page-size
<https://apacheignite.readme.io/v2.1/docs/durable-memory-tuning#section-page-size>
—
Denis
On Sep 13, 2017, at 2:29 AM, Ivan Rakov <ivan.glu...@gmail.com> wrote:
Folks,
We had some experience of benchmarking Ignite with persistent store on SSD. I
think we can share some helpful advice. None of them require changing
configuration of Ignite or persistent store.
*Tuning advice for users*
1) Be prepared for LFS performance decrease after several hours of intensive
load. Unfortunately, that's how SSD drives work:
http://codecapsule.com/2014/02/12/coding-for-ssds-part-2-architecture-of-an-ssd-and-benchmarking/
Consider buying fast production-level SSD drives.
2) Consider using separate drives for LFS files and WAL. Ignite actively
performs writes to both LFS and WAL under intensive load, and having two
devices will double your throughput limit.
3) Over-provision your SSD. Performance of random writes on 50% filled disk is
much better than on 90% filled. SSD Over-Provisioning And Its Benefits:
http://www.seagate.com/ru/ru/tech-insights/ssd-over-provisioning-benefits-master-ti/
4) Leave free space in RAM to let OS use page cache and optimize writes. Total
size of all memory policies shouldn't exceed 70% of your RAM.
5) Make sure that OS doesn't utilize swap. If you use Unix, best option is set
vm.swappiness to 0.
6) Try to find out page size of your SSD. Ideally, page size of Ignite
shouldn't be less than SSD page size. Possible approaches:
Find it in device specification (some manufacturers don't reveal it)
Try running SSD benchmarks
If you are not sure, just set page size to 4K. As various benchmarks use 4K
pages, manufacturers have to adapt drives for 4K random write workload.
Whitepaper from Intel showing that 4K pages are enough:
https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/ssd-server-storage-applications-paper.pdf
Check your OS page cache size. Page size of Ignite shouldn't be less than OS
page size. How to check OS cache page size in Unix:
https://unix.stackexchange.com/questions/128213/how-is-page-size-determined-in-virtual-address-space
Best Regards,
Ivan Rakov
On 01.09.2017 21:08, Denis Magda wrote:
Igniters,
I see a lot of complains regarding the performance of the subj on the user
list. At the same time, I do believe that in most scenarios it’s a lack of
knowledge that we keep in secret.
It's time to document Durable Memory and its Native Persistence tuning parameters.
Let's start doing this for Linux based deployments first. Here is what we have for
now (which is almost nothing):
https://apacheignite.readme.io/docs/durable-memory-tuning
<https://apacheignite.readme.io/docs/durable-memory-tuning>
Ideally, at some point we have to come up with doc like this:
https://access.redhat.com/sites/default/files/attachments/deploying-oracle-12c-on-rhel6_1.2_1.pdf
Please share your expertise in a form of settings that have to be put on the
paper. We put them in JIRA and document afterwords:
https://issues.apache.org/jira/browse/IGNITE-6246
<https://issues.apache.org/jira/browse/IGNITE-6246>
—
Denis
