こんにちは。日々是発見が楽しみな西山です。
OSSでプライベートクラウドストレージを構築できるNextcloud。
自分も自宅サーバーで稼働させているのですが、スマホアプリも利用でき、プラグインでログイン2段階認証やファイル履歴を使えたりと、Dropboxのような商用クラウドストレージと比べても遜色ない機能が利用できるのはすごいと思います。
そんなNextcloudですが、サーバー・ミドルウェア観点で見るといわゆる「LAMP」サーバーですので、PHPやDBの設定調整でパフォーマンス向上が図れます。
今回は「PHP-FPM」と「MariaDB」のチューニングポイントをご紹介します。
「社内共有用にNextcloudを立てたけど、遅いって文句を言われる……」なんてお悩みの方へ、ご参考になればと思います。
PHP-FPMチューニング
1. PHP-FPMプロセス数の設定
PHP-FPMのデフォルトコンフィグでは、起動プロセス数が抑えめの設定になっています。
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
しかしNextcloudを快適に動かすには、この設定値だとPHP-FPMプロセス数がやや不足です。
Nextcloudの挙動を観察していると、ユーザーがアクセスしてファイル一覧画面を開いた瞬間、複数のPHP-FPMプロセスが起動してCPUを消費するのが見られます。
オンラインストレージサーバーなので考えてみれば当然の挙動なのですが……。
なので、プロセス数は多めに設定します。
と言っても、サーバーメモリを使い切ったり、swapを常時食うようでは元も子もないので、freeやtopコマンドで利用状況を観察しながら決めるのがいいでしょう。
自宅サーバーではこのような設定にしています。
pm = static
pm.max_children = 120
pm.start_servers = 12
pm.min_spare_servers = 6
pm.max_spare_servers = 18
2. PHP-FPMプロセスの実行時間・メモリ許容設定
Nextcloudでは容量の大きなファイルを送受信する場合に備え、PHP-FPMはある程度長時間の実行を許可しないといけません。
また、postやupload容量の制限値も余裕を持たせないといけません。
自宅サーバーではこのような設定にしています（かなり余裕めです。ユーザーがたくさんいたり、メモリに余裕がない場合は値を減らす方向で調整するとよさそうです）。
php_value[max_execution_time] = 3600
php_value[memory_limit] = 1G
php_value[post_max_size] = 1G
php_value[upload_max_filesize] = 1G
php_value[max_input_time] = 3600
php_value[max_input_vars] = 2000
3. PHP-FPMセッションファイルをRedis管理に
自宅サーバーではOPcache用にRedisを導入していますが、PHP-FPMのセッション情報をRedisに持たせることができます。
php_value[session.save_handler] = redis
php_value[session.save_path] = "unix:///var/run/redis/redis.sock?persistent=1&weight=1&database=0"
MariaDBチューニング
こちらは特にNextcloud特有の要素はありません。Web上の情報を参考にしつつ、自宅サーバーでは下記の設定にしています。
（インストールデフォルトより多少ましかな？ 程度の感覚です）
[mysqld]
log-bin=mysql-bin
binlog_cache_size=32M
innodb_max_dirty_pages_pct=90
innodb_buffer_pool_size=3G
innodb_log_file_size=768M
innodb_log_buffer_size=16M
query_cache_limit=16M
query_cache_size=256M
query_cache_type=1
read_rnd_buffer_size=4M
sort_buffer_size=4M
table_open_cache = 10K
table_definition_cache = 2K
tmp_table_size = 128M
max_heap_table_size = 128M
performance_schema = ON
skip-name-resolve
チューニングの成果
体感速度は大きく上がりました。特にスマホアプリからアクセスした時のレスポンスが目に見えて改善しました。
以前はフォルダ内のファイル数が多いと一覧表示に長時間かかり、ひどいときはタイムアウトで無反応になったりしていましたが、そういうトラブルはなくなりました。
また、アプリでファイル更新した時の反映もキビキビ動くようになりました。
余談
ここから先はサーバーチューニングと全く関係ない余談です。
こんなに手間をかけてNextcloudサーバーを構築している私ですが、実は有償のDropbox Plusを以前通り契約し続けています。NextcloudはDropboxで障害があった時のバックアップ用、後はDropboxとの連携に問題があるアプリを使う用に動かしています。
二重構成にしている理由はいくつかあるのですが、「自宅が火災や自然災害に遭ったとしても大事なデータは残したい」と思っているのが大きいです。
（2018年の西日本豪雨で、倉敷市真備にお住いのイラストレーターさんが「自宅は水没し全てを失いました」とツイートされていたのが、本当にショックでした……）
NextcloudでもプラグインでAmazon S3をストレージ領域に使えるので、単体で安全なクラウド領域にデータを保存できます。
……が、私が今Dropboxに置いているデータの容量は200GB程度あります。
Amazon S3に200GBのデータをアップロードし、さらに日々閲覧や更新のためにイン・アウトのトラフィックを発生させると、従量課金はどのぐらいになるでしょう……？
Dropbox Plusの月額料金は容量2TBで1,650円（税込み）ですが、ざっくり試算したところ、200GBのAmazon S3の従量月額はそれとトントン、下手すりゃ上回るという結果になりました。
どう考えても「Amazon S3の代わりにDropbox Plusを契約し続ける」方がお得です（年契約や代理店購入で1,650円より安くできますし）。
またNextcloudはセルフホストなので、トラブルが起こっても全部自分で対応しなければなりません。外出中にNextcloudがハングアップしてアクセス不能になっても、泣きつける人はいません……。
有償のストレージサービスを解約してNextcloudに完全に乗り換えるかどうか、そのあたりも含めて検討するのがよさそうです。
