やらなくても動作はするのだが、やっておいた方が精神的に良い設定を行いチューニングする。現在のNextcloudの動作環境はというと、ESXi上の仮想マシンで動作するTrueNAS上のJailで動作という仮想環境の入れ子状態である。管理が楽で便利なのだが、マシンリソースに限りがあるので快適に動作するようにチューニングを行う。
PHPのチューニング
PHPのタイムゾーンを変更
ログはローカルタイム表示だが、occスクリプトを実行したときのメッセージがUTCでコンソール作業で使いにくいので、phpのデフォルトタイムゾーンを日本に設定する。
デフォルトでは設定値がUTCであることが確認できる。
$ sudo su -m www // php実行者権限に変更
% php -r 'phpinfo();' | grep timezone
Default timezone => UTC
date.timezone => no value => no value
% exit // ユーザー権限に戻る
/usr/local/etc/php/php.truenas.ini を編集して、以下追記。
[Date]
date.timezone = Asia/Tokyo
(参考)phpのタイムゾーン名称一覧
設定完了の確認
% php -r 'phpinfo();' | grep timezone
Default timezone => Asia/Tokyo
date.timezone => Asia/Tokyo => Asia/Tokyo
Nextcloudの地域設定
Nextcloudの管理画面を見ると、default_phone_regionを設定しろとワーニングが出ているので、
$ sudo su -m www
www権限で
% cd /usr/local/www/nextcloud
% php ./occ config:system:set default_phone_region --type string --value="JP"
--type stringは無くても良い。
上記のコマンドのように、occスクリプトから初期設定ファイル/usr/local/www/nextcloud/config/config.phpを更新した方が安全。
上記のコマンドのように、occスクリプトから初期設定ファイル/usr/local/www/nextcloud/config/config.phpを更新した方が安全。
新規ユーザーのデフォルト言語が英語になってしまうので日本語に設定
% php occ config:system:set default_language --value=“ja"
% php occ config:system:set default_locale --value="ja"
phpのチューニング
TueNASのNextcloudは大富豪な設定をしており、メモリ限界エラーが出るのでチューニングする。
php-fpmの設定値がデカすぎるので調整。
php-fpmの設定値がデカすぎるので調整。
/usr/local/etc/php-fpm.d/nextcloud.conf の内容を確認する。
pm.max_children = 100 pm.start_servers = 25 pm.min_spare_servers = 25 pm.max_spare_servers = 75
Jailで複数サービスを動かしているホストにとってはmax100は大きすぎる。
topで見るとphp-fpmの1プロセスは77MBメモリを使用する。10プロセス立ち上がるだけで770MBメモリを使う。あまり良くないので設定値をとりあえず1/3に減らす。
pm.max_children = 32 pm.start_servers = 8 pm.min_spare_servers = 8 pm.max_spare_servers = 24
php-fpmを再起動
$ sudo service php-fpm restart
phpプロセスが大量に立ち上がるのは緩和された。もちろんレスポンスはちょっと悪くなるが、個人利用のアクセス頻度あれば体感できるほどでもない劣化なので大丈夫。
MySQLのチューニング
格納している写真が多いせいなのかクエリが引っかかり気味なのと、Preview Generaterで残サムネイル生成とweb閲覧を同時に行うと、swapが足りなくなりMySQLが落ちることがあるのでパラメータチューニングを行う。
MySQLTuner-perl-1.8.3を実行してチェックしてみる。
logファイルの内容チェックもするので、sudoでスクリプトを実行する。
$ sudo ./mysqltuner.pl
問題点をピックアップ
[!!] /var/db/mysql/dev-nextcloud.err contains 237 warning(s).
[!!] Maximum possible memory usage: 11.0G (138.28% of installed RAM)
[!!] Slow queries: 15% (7K/51K)
[!!] Aborted connections: 8.32% (81/973)
[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
[!!] Joins performed without indexes: 362
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (50 %): 256.0M * 2/1.0G should be equal to 25%
[!!] InnoDB buffer pool <= 1G and Innodb_buffer_pool_instances(!=1).
[!!] InnoDB Write Log efficiency: 68.8% (225984 hits/ 328455 total)
General recommendations:
Reduce your overall MySQL memory footprint for system stability
Check warning line(s) in /var/db/mysql/dev-nextcloud.err file
Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1
We will suggest raising the 'join_buffer_size' until JOINs not using indexes are found.
See https://dev.mysql.com/doc/internals/en/join-buffer-size.html
(specially the conclusions at the bottom of the page).
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
join_buffer_size (> 256.0K, or always use indexes with JOINs)
innodb_log_file_size should be (=128M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.
innodb_buffer_pool_instances (=1)
いろいろなconfigを総合すると、必要メモリが11GBになってしまいメモリオーバーしているということがわかる。そこで /usr/local/etc/mysql/my.cnf を修正してメモリ割当量を減らす。
innodb_buffer_pool_size = 1G -> 256M # デフォルトは128MB innodb_log_file_size = 256M -> 64M # innodb_buffer_pool_sizeの25% innodb_log_buffer_size = 64M -> 32M
以前よりもデータ検索に時間はかかるようだが、MySQLがメモリ不足で落ちることは発生しなくなった。
0 件のコメント:
コメントを投稿