【自宅鯖】自作PCの電源を換装する【オウルテック Seasonic SSR-650FM】
6月の頭ぐらいから、ゲーミングPCとして利用していたタワー型の自作デスクトップを、サーバとして利用していた。
Mackerelで監視していたのだが、しばらくは安定して稼働していた。
しかし、ここ2週間ぐらいで不安定になってきた。ログとか見ても特に変なところがない。 連日の猛暑のせいで熱暴走しているっていう線も考えたけど、ほとんどCPU等はアイドルだし、温度を見てみてもそこまで異常値ではなかった。
このPCを組んでもう5年ぐらい経つので電源の寿命ではないかと思い、Amazonでポチって、サクッと換装したレポートだ。
古い電源を取り外す
こんな感じのタワーだ。今から掃除するので寝かせている。 サイドパネルをサクッと開ける。
昔の電源はSilverStone ST75F-Pだ。 750wのフルプラグイン式で80 Plus Silverだ。
別に悪くなかったように思う、ただ単に寿命なのだろう。
電源が刺さっているところ一覧
EATXPWR 24Pin
EATX 8Pin
見にくいけど、マザボの左上にある。
グラボ PCIe 6Pin * 2
ケースファン ペリフェラル4Pin * 2
ここでケースの右サイドのパネルを開ける。 配線汚い😇
こいつが、ケースのファンの電源といろいろ繋がっている。
絵面は似てるけどもう1つ。
HDD SATA15Pin
SSD SATA15Pin
SSD2 SATA15Pin
サーバ用のSSD。1ヶ月ぐらい前に買った、256GB。
DVDドライブ SATA15Pin
全部抜いて外に出す
電源ケーブルの抜き忘れがないように、ケースの外にケーブルを全部出して、全部抜いたかを確認する。
電源を固定しているネジを緩めて外す
4箇所ネジで止まっているので外す。
ホコリが少し溜まっている。
プラグイン式の電源は使うものだけ挿せばいいので、電源の前に使わないケーブルをまとめておかないくていいのでオススメである。
掃除
ケースは、今はなきZalmanのZ12 Plus。
フロントパネルをガバッと外す。結構硬い。
フロントパネルのファン。汚い。
フロントパネルに付いてる、フィルターを取ってみる。
うげぇ〜、汚い。
ケース底部のも掃除しておく。
ここでちらっと写った掃除機は、ダイソンのコードレス。 一人暮らしするときに、母に強くダイソンの掃除機をオススメされて購入に至った。
新しい電源
新しい電源はオウルテック Seasonic SSR-650FMを選択した。
この電源を選択した理由
- 信頼できるメーカー
- 驚きの7年間保証
- 80 Plus Gold
- サブプラグイン式
電源容量は、50% のときの一番効率よく変換できるので、50% + αになるように組む。
電源容量の見積もりは、電源容量計算(電源電卓)電源の選び方|ドスパラ通販【公式】 が大変参考になる。
開封の儀。じゃ〜ん。
電源に小物入れ(?)がついていてびっくりした。
電源は、メイン以外はプラグイン式になっている。 電源コードがわかりにくいけど、平麺みたいになっていて薄くて配線しやすかった。ベビースタードデカイラーメンみたいと言えばわかりやすいだろうか。
仮組み
意図せず、ブラックとゴールドが揃っていてかっこいい。
EATXPWR 24Pin
【プラグイン】ペリフェラル4Pin
【プラグイン】SATA 15Pin
【秘技】空中マウント
良い子は真似しない。
メモリテスト
ここで、サイドパネルとか開けたまま、メモリテストを回してみる。
電源のピンの刺し忘れや、メモリがちゃんと認識するかのテスト。*1
今回初めてメモリテストをしたが、memtest86+というのが定番らしい。
grub2から起動すると、何もしなくてもテストが回り始める。 このテストは自動的に何回もループするようで、3回ぐらい回すのがいいらしい。
一晩放置して、Pass: 4, Errors: 0 と出ていたので、メモリは大丈夫そう。
サイドパネルを閉めていく
組み立てているときに、今回このPCをサーバ用と割り切ることにして、HDDやWin用のSSDやGTX 970も取り付けるのをやめた。
安定性が増すことや、アイドル時の電気代を加味するとその方が良い選択な気がした。(が、今回650wを選択した意味がなくなってしまった。)
まとめ
換装前は半日で落ちていたサーバであったが、今回の電源の換装で安定してサーバが稼働するようになった。
完全に結果論だが、電源の寿命という推察はだいたい当たっていた。
オウルテック 7年間新品交換保証 80PLUS GOLD取得 ATX 電源 ユニット セミモジュラー Skylake対応 Seasonic FOCUSシリーズ 650W SSR-650FM
- 出版社/メーカー: オウルテック
- 発売日: 2018/03/23
- メディア: Personal Computers
- この商品を含むブログを見る
*1:本当はメモリが原因か、電源が原因か見極めるため、電源交換前にもやるべきだった。
【Golang】GitHubのAPIでIssueのコメントを全件取ってくるスクリプト
昨日モテるシェル芸とか言って、ブログ書いてたんですけど、
実はGitHubのIssueのコメントが大量すぎて、Load more
になっちゃってて、全部の画像をダウンロードできてなかったみたいです。
それをデザイナーに指摘されて、全部取ってこようと思ってGitHubのAPI見てたら、Headerに次のページのlinkが入っているという仕様で、シェルスクリプト書くぐらいならGoで書きたいな〜と思ってGoで書きました。
GitHubのTokenを取得する
GitHubのパスワード認証だけだったらわざわざToken取得しなくてもいいんですけど、2段階認証している方はTokenの取得が必要となってきます。
https://github.com/settings/tokens にアクセスして、Tokenを取得します。
スクリプト
が便利です。
使い方
Passwordをベタ打ちしない方法は、Qiitaに書きました。 qiita.com
あと、constのrepoとかownerは自分のものに変えてください。
read -s 'TOKEN?tokenを入れてください>' go run main.go | xargs wget
上記コマンドでIssueの画像が全件ダウンロードされるはずです。 されないときは、正規表現等が怪しいと思うので、その辺りを修正してください。
まとめ
これで、デザイナーから「おい!全部じゃねえぞ」ってツッコミが飛んでこなくなりましたね。*1
めでたしめでたし。
*1:実際にはそんなツッコミは飛んできていません。
【裏技】みんな知らないログイン必須ページの爆速スクレイピング【モテるシェル芸】
おはようございます。
裏技ってつけると急にワザップ感が出て、懐かしいですよね〜。 こないだ飲み会で同期とそんな話をしておりました。
本題
ログインが必要なWebサイトで画像を引っこ抜いて欲しいという依頼があり、スクリプトを書くかな〜と迷ったんですが、よく考えたらシェル芸だけで出来るな〜と思ったので共有したいと思います。
今回はデザイナーにGitHubのIssueに貼ってある画像200枚以上をzipで欲しいって言われたので、それを題材にします。
環境
やり方
1. Chromeでおもむろにデベロッパーツールを開く
Macなら Shift + Cmd + c
等で開けます。
2. networkを選択する
そのページのリクエストを見つける たぶん、一番上のはず。
3. 右クリックして、Copy as cURLを選択
今回の肝はこれで、ブラウザで送ったリクエストと全く同じリクエストをcurlで再現できるようになっております。 つまり、cookieの情報等も渡してくれるので、認証が通った状態でアクセス出来るわけですね。
GitHubのプライベートリポジトリは、認証してない状態でアクセスすると404を返してくるのですがそれを回避できます。
4. お好きなターミナルにコピペ
わかりにくいですが、めっちゃ長いcurlコマンドが貼り付けられてます。
5. いい感じにシェル芸してく
今回は、Issueに投稿された画像を抜いてきたいので、こんな感じになりました。
curl github.com/.../../ -H '....' \ |grep '<img' \ |egrep -o "https://user.*?\.(png|jpg)"\ |uniq\ |xargs wget
一応説明しておくと、
grep '<img'
で当たりをつける- grepの拡張版であるegrepで正規表現を使っていい感じに抜き取る (oオプションはマッチした場所だけ取ってくる便利なオプションです。egrepじゃなくて、grepのEオプションでも可)
- 何個か重複してたりしたので、uniqをかませる
- xargsでwgetにurlを渡す (ここで意外なのが、画像には認証が不要というとところです。 uuid振ってあるから、大丈夫という認識なのでしょうか?)
まとめ
これを頼まれて5分ぐらいでサクッとやって「出来たよ」って言って渡せば、モテること間違いなしですね!!!!
(念の為言っておきますがこれでモテていると勘違いしているわけではありません。24年生きてるので、それぐらいわかっているつもりです。)
go run main.goとすると別ファイルのmainパッケージのグローバル関数がundefinedで怒られる
めっちゃ久しぶりのブログになってしまった。
書くことなんか何個でもあるのに、バタバタしてたりでアウトプットを疎かにしていた。(言い訳)
本題
少し前から気になってたことだったんだけど、go run main.go
で実行すると、mainパッケージの別ファイルのグローバルな関数の呼び出しができない。
最小構成のリポジトリを作った。
これを、適当にcloneして、 go run main.go
すると実行できない。
最小構成のサンプル作った。https://t.co/nvec9r5CYq pic.twitter.com/XEFZQaj9Ge
— serinuntius (@_serinuntius) July 15, 2018
解決策
buildする。
go build -o main && ./main
で buildすると実行できる。
どうしてもgo runしたいときの解決策
1. go run main.go lib.go
ファイルを列挙する
ルートにファイルが増えると面倒なので、できたらやめたほうがいいと思う。
2. go run *.go
*でごまかす
この方法は楽なんだけど、テストのファイル(例) main_test.go)があると破綻する。
同じようにハマってる人がいた
この件で不思議なのは、main以外のパッケージだと普通に読み込めるところ。 例えば、こういう構成だったら大丈夫。
root/ --- main.go --- lib/ ------ hello.go
この場合は import "host/username/root/lib"
というふうにimport文を書くからそこから解決して実行できるんだろうな(想像)
これ、初めて遭遇したときはびっくりするんだよな。
kamakura.go #4 に登壇しました!
昨日(2018年5月25日)行われた、kamakura.goのLTで以前から書いているGoのパッケージであるgraqt(がらくた)の紹介をしてきました。
前回のgraqtの記事
発表資料
登壇後に質問されたこととか
(あいまいな)記憶と #kamakurago のハッシュタグを辿りながら書いてます。
Q. トレーサーのオーバーヘッドは? 5%以下の性能低下なら、良いよねってなんかの本で書いてたよ〜。
A. 実際、オーバーヘッドはあります。以前検証したベンチマークでは、以下のようなことがわかっています。
1リクエストで発行クエリが増えれば増えるほど、オーバーヘッドは大きくなる。(当たり前ですが)
1リクエストで、1クエリーだった場合のオーバーヘッドは、
- ログあり1547.08 Requests/sec
- ログなし1607.31 Requests/sec
1547.08 / 1607.31 * 100 = 96.25274527 となり、5%以下になっている。
しかし、1リクエストで、100クエリーだった場合のオーバーヘッドは、
- ログあり 58.89 Requests/sec
- ログなし 54.56 Requests/sec
で、
54.56 / 58.89 * 100 = 92.6473085413 となり、5%を超えてしまっている。
便利そうですね。応援しています。
ありがとうございます。そういってもらえて嬉しいです。
まとめ
今後もGo書いてくぞ。
【追記アリ】Golangで1行1行がJSONのログを効率的にパースする
この記事でも書いたけど、ISUCON用のロガーを作ったので、そのログをパースするツールを書こうと思った。
少しパフォーマンスを意識して書いてみたけど、きっともっとパフォーマンスが良くなる気がするのでマサカリウェルカムです。
続きを読む