Skip to main content

After installation - System tuning

We offer you several steps to achieve maximum performance of the system

If your network is small and your server has no problem with high CPU load - you can skip this page

Hardware

The first and main recommendation is to keep Grusher and operating system up-to-date. Today not possible to use "install and forget" principle. Updates are released help to improve performance and resolve issues.

Second recommendation for highly loaded systems is to separate the web server (Application) and database (DB) on different servers or virtual machines. This will help balance processor time and memory for each machine, and there will be no competition for a shared pool of capacity.


Software

MariaDB tuning

At the time of writing this article latest version was 11.8.3 LTS.

MariaDB Server 11 brings many significant improvements to the query optimizer! 

Read this articles 

Also you can use clustering (Galera Cluster) from MariaDB.
MariaDB config file for performance (optional, use on your own risk)

This config is optimise for VM with 6 CPU and 10 RAM. The database server is separate from the application

[mariadbd]
# Enable the performance schema.
performance_schema = ON
#Skip DNS resolving
skip-name-resolve = ON

#The number of file I/O threads in InnoDB is set by the options innodb_read_io_threads, innodb_write_io_threads
#usually this parameter is set to 4 or 8, on fast SSD drives set to 16.
innodb_read_io_threads = 16
innodb_write_io_threads = 16
#Enable/disable InnoDB deadlock detector (default ON). if set to OFF, deadlock detection is skipped, and we rely on innodb_lock_wait_timeout in case of deadlock.
innodb_deadlock_detect = 0
innodb_lock_wait_timeout = 3000
#Number of undo tablespaces to use.
innodb_undo_tablespaces=8
#Enable or Disable Truncate of UNDO tablespace.
innodb_undo_log_truncate=ON
#Desired maximum UNDO tablespace size in bytes
innodb_max_undo_log_size=2G
#Dictates rate at which UNDO records are purged. Value N means purge rollback segment(s) on every Nth iteration of purge invocation
innodb_purge_rseg_truncate_frequency=64
#The size of the memory buffer InnoDB uses to cache data and indexes of its tables.
innodb_buffer_pool_size = 6G
#Size of each log file in a log group.
innodb_log_file_size = 2G

#Other
#The size in bytes of MyISAM key cache, which is the buffer used for MyISAM index blocks.
key_buffer_size        = 128M
#The number of cached table definitions
table_definition_cache = 405

# Logging
log_output=FILE
slow_query_log_file = /var/log/mysql/slow.log
slow_query_log
long_query_time = 10.0
log_queries_not_using_indexes=0
log_error=/var/log/mysql/mariadb.err

The following optimizations may cause a small loss of data in case of crash but reduce CPU usage by up to 50-70% !!!

# binlog is not flushed after each write
sync_binlog = 0

# If you can tolerate losing 1 second of transactions on crash set to 2
innodb_flush_log_at_trx_commit = 2

# removes double cache and speeds up disk operations.
innodb_flush_method = O_DIRECT
innodb_doublewrite = 0

Ngnix

If you have a lot of active system users (more than 10) or you actively use the Grusher API, you need to configure php-fpm.

Otherwise, requests submitted to the web will take a long time to be processed.


Grusher

APP_ENV=production

Do not use too many pollers. Everything should be in moderation. Do experiment with different numbers of pollers and determine the most optimal count.

Do not run heavy tasks too often via scheduler

Database optimisation

Add to CRON once per week/month  Database periodical optimisation