前言：
我的nas是DIY版，系統(tǒng)是debian的omv偏螺，網(wǎng)上有很多教程，以前是黑裙矾瑰，不喜歡盜版砖茸，喜歡開源免費，教程不表殴穴。
可以參照這個文章：https://www.noobyy.com/nas
私有云大致對比了下nextcloud和seafile凉夯，seafile加密不明文货葬，沒法smb，就用nextcloud劲够。docker安裝震桶，1分鐘搞定，美滋滋征绎。
問題和解決過程描述：
裝完之后確實可以用了蹲姐，但是遇到了性能問題：局域網(wǎng)傳輸都僅有1-5M/s ，初始化數(shù)據(jù)庫人柿，網(wǎng)頁打開都非常慢柴墩，這沒法用啊。排查：
0凫岖、換版本：把nextcloud江咳，和mariadb都換了舊版，一樣沒效果哥放，不是程序代碼問題歼指，他們的程序員沒那么差。
1甥雕、網(wǎng)絡(luò)問題踩身？ smb傳輸可以跑到磁盤寫的極限，70M/s社露，所以肯定不是網(wǎng)絡(luò)問題挟阻，是程序在我的環(huán)境下遇到了什么問題。
2呵哨、top命令赁濒，負載較高，cpu很低孟害，磁盤IO瓶頸。iotop看一下挪拟，發(fā)現(xiàn)apache httpd每秒寫幾M挨务，但是整個磁盤每秒寫50M？奇了怪了玉组。除了apache之外谎柄，mysql的io也很高。但是加起來磁盤寫也沒有50M惯雳。
3朝巫、換個磁盤試試？docker掛載另一塊盤石景，發(fā)現(xiàn)效果非常好劈猿，初始化快拙吉，讀寫速度都不錯【救伲肯定是硬盤問題筷黔。（一定用docker裝啊，太快了仗颈，隨便換）
解決點1：（大多數(shù)沒有這個問題佛舱，可以看看，然后忽略）：我的硬盤是之前黑裙糟蹋過的btrfs挨决，甚至還組了raid请祖，感覺一直在雙寫，總之不健康脖祈，性能很差损拢，估計碎片，空洞什么的很多吧撒犀，具體我也不懂福压。處理他，備份數(shù)據(jù)或舞，格式化荆姆，ext4格式，raid也沒了映凳。效果不錯胆筒，局域網(wǎng)用1個3G的文件上傳nextcloud，瞬時速度可以到30-50M每秒了诈豌，雖然不太完美仆救，總之好多了。
新問題：之前測試都是用一個大文件矫渔，速度還不錯彤蔽，但是偶然間用幾千個文件的文件夾拖拽上傳，cpu很快上去了庙洼，IO負載很高顿痪，寫入速度上不去，局域網(wǎng)10幾兆每秒的樣子油够，和一個大文件上傳截然不同蚁袭，按照程序員排查問題的經(jīng)驗，肯定是碎文件在不斷創(chuàng)建和寫庫有性能開銷石咬。
繼續(xù)看top揩悄、iotop、vmstat等：cpu 50%鬼悠，io很高删性，mysql的IO占比很高亏娜，apache畢竟上傳速度那么低，很低镇匀，mysql有點喧賓奪主了吧照藻？
mysql在做什么，這么點速度汗侵，那么高IO幸缕。登陸mysql容器，show processlist晰韵；發(fā)現(xiàn)全是在做文件鎖发乔，鎖這種東西用mysql sql語句不太合適吧？按照官網(wǎng)建議改redis雪猪，畢竟是內(nèi)存栏尚。
解決點2（非常關(guān)鍵）：給nextcloud配置redis鎖（網(wǎng)上有很多nc性能優(yōu)化都提到了這個）
docker裝redis，修改config.php只恨，增加鎖的引用译仗。
效果非常明顯，sql語句只有insert 語句了官觅，這個是正常的纵菌。IO也沒之前高了。
但是硬件瓶頸這個東西休涤，只看木桶最短板咱圆，再傳文件夾，碎文件功氨，iO雖然不是問題序苏，但是cpu100%了，磁盤寫速度從10m提升到了30M左右（我心中50-70M每秒）捷凄。還是mysql IO最高忱详，我有點心灰意冷，認為nextcloud纵势，除了寫磁盤對mysql使用過高踱阿，吃機器性能。對比了一下其他的私有云產(chǎn)品钦铁，感覺還是得回來繼續(xù)優(yōu)化，不行就打算看看nextcloud源碼才漆，看看put方法都在做什么牛曹，能不能減少點sql調(diào)用。先嘗試優(yōu)化下mysql醇滥，畢竟是個硬盤讀寫的中間件黎比，網(wǎng)上搜了搜超营，mysql性能優(yōu)化，改了一個參數(shù)阅虫，世界美好了演闭。
解決點3（最最關(guān)鍵）：
mysql 進去，看看變量颓帝，SHOW VARIABLES like '%flush%' 一看米碰，?innodb_flush_log_at_trx_commit? 這個參數(shù)默認是1，就是最安全购城，性能最差的吕座，改成0（找到my.cnf，docker卷下找到2個瘪板，全改了吴趴，重啟mysql容器），我可以接受1秒宕機侮攀，數(shù)據(jù)庫丟失锣枝，因為數(shù)據(jù)庫全掛了，nextcloud還可以通過scan命令重新掃描兰英。改成2的話撇叁，就是折中，沒必要箭昵，直接改成0税朴。
性能非常完美，碎文件上傳家制，wifi鏈接的情況下正林，50-60M每秒，硬盤瓶頸也就這樣了颤殴，cpu跑滿觅廓，IO最高的已經(jīng)變成apache的多線程了，這個估計用nginx和phpfrm也能優(yōu)化涵但，沒必要了杈绸，心累了，速度夠用了矮瘟。先告一段落吧瞳脓。
這樣的nextcloud還有點好用。
總結(jié)：整體思路就是澈侠，在硬盤和網(wǎng)絡(luò)沒問題的情況下劫侧，讓程序減少使用mysql，減少sql語句，同時讓mysql高性能工作烧栋，少做無用功写妥。
主要命令：top、iotop审姓、vmstat珍特、iostat足夠了。
后來網(wǎng)上看到很多人說魔吐，nextcloud太吃性能扎筒，我想對于程序員 運維之外的人群來說，確實是太吃性能了画畅，不是做這個的砸琅，誰能知道優(yōu)化mysql的刷盤策略，以及用緩存替代文件鎖呢轴踱。
過程比較復(fù)雜症脂，很多命令和細節(jié)沒寫，也踩了很多彎路淫僻，做了很多嘗試诱篷，還有一些其他的坑，回想著列一下：
1雳灵、nextcloud日志（在data目錄里）里redis報exception棕所，說什么protected-mode保護模式，修改一下redis配置文件悯辙，改成off琳省，重啟，不報了躲撰。
2针贬、nextcloud 任務(wù)從ajax改成cron，nas里配置cron命令拢蛋，網(wǎng)上有文章桦他。【對于網(wǎng)頁打開速度能加快谆棱？】
3快压、mysql binlog關(guān)閉，沒什么用垃瞧，還是那句話蔫劣，mysql掛了都沒問題，有文件就可以个从，重新掃描拦宣，命令：docker exec nextcloud su www-data -s /bin/bash -c "php /var/www/html/occ files:scan?—all”? 【應(yīng)該有點用】
4、ext4的硬盤jbd2進程IO占比過高信姓，網(wǎng)上有優(yōu)化辦法鸵隧，鏈接找不到了∫馔疲【不過效果不明顯】豆瘫。
