ブログ

追記（オチ）
UEFIからCPBとPBOを無効化したらCPU温度はおとなしくなりました。
PBOはあまり差異を感じなかった感じです。
CineBench R23は22300程。LNA無しの室温20度でCPUは55度弱です。
UEFIも触ってみるものですね。

完全に雑記です

PCの温度が高いことに気付いた。
CPUはAMDのRyzenなので、サーマルスロットリングを起こす90度ギリギリです。
VRM温度は詳しく知らないけど、まあ良い温度には思えない。
何より、どちらも精神衛生上よろしくない。

ということで、PCに手を入れました。自作機なので好き勝手出来ます。

1. マザーボード変更
   B550M AORUS PRO から B550M AORUS PRO-P に変更。
   一見同じだけど、VRM周りが違う。
   10+3フェーズVRM 低RDS（ON）MOSFET から、10+2 DrMOSFET になっている。
   詳しくはないが、ドライバーMOSFETはだいぶ発熱が小さいとのこと。元々も低発熱と言うけど、80度まで上がってしまっている。
2. CPUクーラーの変更
   NH-U9S からNH-U12A （LNA使用）に変更。
   こちらは純粋に同じメーカーの上位版に置き換えの方針。
   一応Noctua公式では、NH-U9Sでも問題ないと表記されているけど、実際88度まで上がってしまっている。

結果です。これだけ変わりました。
VRM温度は30度下がりました。
CPUは14度低下ですが、LNA使用で性能が下がってこれです。グリスの性能も最初は発揮されないとのことだし、何よりこれだけ下がれば満足です。
ちなみにLNAを使用したのは、騒音が酷くなったからです。仕様上の騒音値は22.8dBAから22.6dBAに下がっているので、ケースとの相性が悪いのでしょう。

おまけ、今回負荷に使ったCinebench R23の結果です。
改修前
改修後
22556ptsから25079ptsにスコアアップしました。

SynologyのDSMを7にアップする際、今までのGitLabが存在するとアップできない為、別のGitLabへ移行した際のメモです

参考にする場合は自己責任でお願いします

• 移行元
  • Synology DSM 6.2.4-25556
  • Synology のパッケージマネージャから入れたGitLab
  • GitLabのバージョンは13.12.2-0072
  • 実態はSynology DSMで動いているDocker上で動くGitLabコンテナ
    • gitlab本体以外にPostfresqlとredisが付いてくる仕様
• 移行先
  • GitLab CE のDockerコンテナ（GitLabが提供しているイメージから）
  • 深く考えずlatest
  • Synology DSM上のDocker上で動かす
    • 他のコンテナに依存しないスタンドアロン仕様

以下移行した手順

1. Synology DSMのDocker GUIからgitlab/gitlab-ceを検索してイメージを取得
   1. 深く考えずlatest
2. イメージからコンテナを起動する
   1. 次のURLを参考に、dataとlogsとconfigをコンテナの外に保存する設定を追加
   2. https://docs.gitlab.com/ee/install/docker.html
3. 新しいGitLabを起動後、最初に画面を開いた時点でrootのパスワードを設定する
   1. と以下のURLに書いてあるが、設定画面が出てこない
   2. https://docs.gitlab.com/ee/install/docker.html
   3. 代わりに、以下を参考にしてコマンドでパスワードを設定する
   4. https://docs.gitlab.com/ee/security/reset_user_password.html#reset-your-root-password.
4. 普段のユーザーを追加
5. 古いGitLabから新しいGitLabにリポジトリの移行
   1. 古いGitLabでgitlab-rakeコマンドが無いのかパスが通っていないのか、一括で移行できそうな方法が無理なので断念
   2. 新しいGitLabから古いGitLabのリポジトリを指定してクローン、Dockerのホストが同じためIPが同じで拒否され断念（ポートが違うけど見てくれない）
   3. 古いGitLabでリポジトリをエクスポートして、新しいGitLabでインポートする。これは上手く行った
6. その他、必要なら設定

特にエクスポートからインポートで消えるデータなどは気にする必要が無いので楽でした。とはいえ本来ならコマンドで一括かつ簡単に移行できそうな所なので、調査不足感は否めない終わりでした

DS218jのHDDに、WD Blue（CMR）が入っている
久しぶりに確認してみたら、PowerOnHoursが94まで低下していた

Power_On_Hoursが94まで低下。生データは4420（時間）

ということで、この値が0になるまでの時間を計算してみる（24時間稼働）

4420/6*100 = 73666時間
4420/6*100/24=3069日
4420/6*100/24/365=8.4年

筐体の陳腐化のほうが早そう。実際DS220j出ているし

データ保存の為のNASを新調した結果、色々とあったのでちょっと書いておきます
218jで試したけど、試してる間に220j出たよ

結論

• アプリ入れるならCMRなHDDを入れた方が良い

アプリ一切入れないならSMRでも良いかも。でもSynology NAS使う理由もなくなる。

比較方法

• DS218jにHDDを入れて、各HDD毎に共有フォルダを切る
  • SMR：SeagateのST4000DM004
  • CMR：WDのWD40EZRZ
• 1回目：初期状態で何もアプリを入れずにベンチマーク
• 2回目：WDにSynology Driveと依存ソフトをインストールしてベンチマーク
• 3回目：STにSynology Driveと依存ソフトをインストールしてベンチマーク

アプリケーション追加なし

WD40EZRZの方。特に変な場所は無し
ST4000DM004の方。こちらも問題なし。
これだけ見れば、安くて高性能なHDDです。

WD40EZRZにSynology Driveをインストールする

アプリはインストール先が選べるので、両方試す
今回はWD40EZRZが不利です

不利なはずのWD40EZRZの結果。有利なST4000M004と同じ結果を出している。 こちらはST4000M004。有利なハズだが劣化がひどい。
体感速度の劣化はもっと酷く、ベンチマークは終わる気がしない。

ST4000M004にSynology Driveをインストールする

今度はST4000M004が不利なパターン
もしアプリインストール先の影響がなければ、同じ結果になるはず

まずWD40EZRZ。Synology Driveインストールし忘れたか不安になる結果 そして今回の主役、ST4000DM004の結果
壊れたかと思うくらい遅い

おまけ

その他、気づいた点
どれもこれもST4000DM004に対して良くない印象を得る

CMRなWD40EZRZにSynology Driveをインストール
WD40EZRZのベンチマーク後に、ST4000DM004のベンチした結果
見ての通り、ST4000DM004はI/O待ちが酷すぎてCPUが遊んでいるし、HDDも余裕なWDに対して必死感が伝わってくる。

SMRなST4000DM004にSynology Driveをインストール
WD40EZRZのベンチマーク後に、ST4000DM004のベンチをした結果
ベンチが終わった直後に、謎の負荷が跳ね上がっている。SMRをDBとして使った結果だろうか？
HDDの方は分かりやすい。DBとして使っているだけなのにST4000DM004の必死感が伝わってくる

おまけのおまけ

STのベンチマーク直後の結果はどうなっていると思う？
わかるだろうか、通信はもう終わっている（右下見て）
なのにST4000DM004は負荷がかかったまま帰ってこない
Synology DriveをWDにインストールしようがSTにインストールしようが変わらなかった
この状態、結構長く続くので高頻度で注意。今回のベンチだと1時間くらい維持した気がする（計ってないので体感です）

以前は横にしか繋がらなかったが、縦にもつながるように改善
あと投げた画像を開いたままつかんでいた不具合を修正

縦と横の切り替えはモード切替にしようかと思ったけど、使用時に手間だと思ったので単純にフィールドを区切りました

dlページ
https://nekomatagi.com/works/pngtunageru.html

気が向いたので透過pngを繋げることにした。横に。

dlページ
https://nekomatagi.com/works/pngtunageru.html

使い方。
起動して透過pngを投げるだけ。

使った例。元png1、元png2、結果