Intel PRO/100S

10数年間、共に戦ってきたIntel PRO/100Sがついに引退しました。
自宅にファイルサーバを構築したことでギガビットの必要性が生じたため、安定性抜群の彼もついにお役御免となったのです。

s_DSC_0165

チップの刻印は00年になってますが、その頃は1万円くらいする高級パーツだったので大学生~新社会人だった頃の私には躊躇する商品でしたので、買ったのはもうちょっと後の中古品でした。

当時の自作事情は今のように、当たり前のようにM/BにLANが搭載されているわけではなかったので、NIC(LANカード)を買うのは普通だったのですが、数千円以内で買えるNICは安定性や速度に問題があることが多いのでした。
そんな中でも、NIC MANIAというサイトで調べたりして、
1000円ほどで買える中では評判の比較的良いSiS900チップ搭載のNICを秋葉原で探し回ったりした記憶があります。
それでもやはり当時の最高峰NICであるIntel PRO/100Sには、安定性、CPU負荷、速度でまったく敵わないのでした。

そんな憧れだったIntel PRO/100Sを、2000年代始め頃に中古で(たぶん)3000円くらいで手に入れてからは、2015年2月の今日までの10数年間、自宅でインターネットに接続する際には、必ずこのパーツのお世話になり続けたのだと思うと、ちょっと感慨深いものがあります。これほど長く使えたパーツは他にないです。

2014年振り返り

プライベート

  • 初子が産まれる。
  • 子供を撮るために一眼カメラを始める。
  • 子供が産まれて嬉しくてはしゃぎすぎて暴飲暴食してしまったのか、痛風になる。軽度だったこともあり、反省してビールや肉食を減らし、投薬無しで尿酸値を下げると誓う。
  • 自分の部屋を作る。
    家は5部屋あるのに、これまで自分だけの部屋が無かった。自分の部屋を作ってからは一人で映画鑑賞、PC、ゲーム、読書、居眠りと、リラックス出来る環境をゲット。

仕事(部長として)

  • 現状の技術開発部、及び各チームや個人の弱い部分を分析し、それを補い、成長させるような具体的な施策をいくつも実施し、良い効果を上げることが出来た。
    前年に関しては、あまり独善的な施策を実施/指示することに抵抗があり、それほど指導的な上司ではなかったと思うので、自分的には大きな進歩。
  • 少数のエンジニアでAdStir/Bypassという大きなサービスを開発・運用する体制を考え、整えることが出来た。コアメンバーの退職もあったが、問題なく、変わらず業務を遂行させることが出来た。
  • 2015年はもっとコアなメンバーを増やすことが課題

仕事(エンジニア個人として)

  • (着手は2013年からだが)新DSPの入札/配信部分をほぼ一人で作り上げ、徐々に増えるリクエスト(秒間何万req)を捌くために試行錯誤したのは、WEBエンジニアとしても、広告エンジニアとしても成長出来た1年だった。
  • 2014年後半は、その新DSPの入札ロジックを自らのアイデアで大きく改善し、収益を上げることが出来た。
  • 巨大化するAdStir/Bypassのインフラを安定的に構築/運用することが出来た。
  • とはいえ、マネージメントやPM/PL業務、インフラ系業務が多いため、コーディング量は減っている。WEBに生きる1プログラマとしては少々焦りを感じてたりする。

SONY α6000を購入

デジタル一眼が欲しくなったので、一眼レフ、ミラーレス一眼をいろいろ調べた結果、
SONYのミラーレス一眼α6000を買いました。

いろいろ調べた結果、
もし今後カメラにはまるとした場合、
(1) レンズが欲しくなった際の選択肢が少ない
(2) それでもレンズを買ってしまった後に、他のメーカーのカメラの購入を考えた場合レンズ流用が出来ない
などの理由から、後悔する可能性はありそうですが、

今後も、初~中級レベルのカメラ一台のみの所有に限った場合、
(1) ミラーレスなのでコンパクト
(2) 2014年9月時点で、全体的に高スペックで最高レベルのAF性能と連写性能
という理由から長く付き合えそう。

素人なので、
「オートにしておけば、それなりに綺麗に撮れる」
というのは、心強いです。

初撮影

花

屋内LAN配線工事やるよ

5年くらい前に家を建てた時に、施工業者に全部屋(5部屋)にCD管だけ通して貰い、入居後よく使う3部屋にだけ自分でLAN配線したのですが、今回もう一部屋有線LANが必要になったので写真を撮りながら解説気味に記事書きます。

まず必要なものから。

s_IMG_0938[1]

LANケーブル(今回使ったのはCAT5e)
LANコネクタ(RJ45) 
LANケーブルとコネクタを圧着するための工具
LANモジュラージャック(コンセント埋め込み)
ビニール紐(←重要)

あとは、
掃除機(なるべく強力なもの)
強力な接着テープ

LANケーブルについては、部屋の配置によってCD管の配管が思ったより距離が長かったりしますので、長めのものを買った方がいいです。一箇所のみであれば5〜10M程度でもいいと思いますが、余ったとしても、部屋の中の配線でも自分で作ったりしますので、余裕をもって買いましょう。
LANコネクタは数百円で10個入りを買えると思います。工具はそう何度も使うものではないので安いものでもいいかと思います。写真のものは1000円程度だったと思いますが、ケーブルの切断、表皮だけの切断も出来ます。
ケーブル、コネクタ、工具の三つがあれば、今後好きな長さのケーブルが必要になった時にもすぐ作れますので便利です。
LANモジュラージャックは、1000円前後でホームセンターで売ってます。写真の物はこの部品にケーブルを圧着するタイプです。(5年前は壁側もモジュラージャックになっているものを使ったのですが、今回方々探しても見つかりませんでした。生産中止でしょうか)

s_IMG_0939[1]

まず部屋側。コンセントのカバーを外します。
左上にオレンジの配管がありますが、これがCD管です。LANケーブル等のトンネルになる管です。
(ちなみに、右の方に電気配線がありますが、こちらには電気工事士の資格がいりますので触ってはいけません)

次は、接続先のスイッチングハブが置いてある所。つまり全てのCD管が集まっている所です。
我が家の場合、全部屋からお風呂場の天井裏に向けてCD管が伸びています。

s_IMG_0940[1]

s_IMG_0941[1]

家を新築する場合(または建売でも施工前か施工中の場合)は、是非このCD管を通しておくことをお勧めします。5年前のことなので、ちょっと記憶が定かではないのですが、5部屋分通して3〜5万円だったと思います。
最近は無線LANも高速になりましたが、やはり安定性やレイテンシの点で有線に大きく劣ります。
用途は有線LANに留まりません。全部屋を「何か」でネットワークするための管です。今後の何かのためにも引いておいても良いかと思います。
あと、これは予想ですが、外から電話線を引く部分からもCD管を通しておけば、フレッツ光などのインターネット回線を引く際に好みの部屋にルーター設置のための配線工事を行えるはずです。うちはそうでした。

s_IMG_0942[1]

スイッチングハブは、天井裏で延々と動き続けることになりますので、安定性の高いものを購入しましょう。部屋に置くようなものであれば、フリーズしても再起動するなどの措置が簡単に出来ますが、天井裏だとそうもいきません。
そんなに高級でなくてもいいのですが、
* メタル筐体であること
* 電源内蔵型であること
の二点は気にした方が良いです。どちらも発熱の問題ですが、後者については配線がシンプルであるというメリットがあります。
(そもそもの発熱が少ないことも大事ですが、これは口コミなどで調査するしかないですね)
写真のスイッチは機種名は忘れましたが、Buffaloの1000BASE-Tの5ポートのもので数千円程度のものかと思います。この5年間無停止で動き続けていますので大変優秀です。最大5部屋分なので5ポートのもので良いので安価に収まりました。

では配線工事スタートです。
ビニール紐をCD管に差し込んでいきます。出来るだけ奥に。
(いきなりショボイ作業ですが、これが全工程で一番大事な作業ですw)

s_IMG_0944[1]

次は、(お風呂場の)天井裏の方のCD管に掃除機のノズルを差込み、吸引します。部屋側に差し込んだビニール紐を吸うわけです。
(掃除機で吸いながら写真取るの無理なので、写真はありません)
ここで使う掃除機の吸引力が弱いと、この工事はここで中断になってしまいます。Makitaの充電式掃除機(業務用でも使われる割と定評のある掃除機)も持っているのですが、それだと無理でした。

尚、ビニール紐をさす側と掃除機で吸う側は逆でも勿論かまいません。
我が家の場合は、CD管を通してくれた施工会社が、どの管がどの部屋なのかを分かるようにしてくれていなかったので、この方向にしています。

s_IMG_0945[1]

すると、ビニール紐だけ通った状態になります。
ちなみに、専門の業者の場合、この作業を(当たり前ですが)ビニール紐ではなく専用の工具で行います。
フレッツ回線を通した時に業者の作業を見学してたのですが、強度のある針金のようなものをCD管に通していました。
(前述した「どの管がどの部屋か分かるようにしてくれていなかった」のは、業者が気が利かないという訳ではなく、この方法で部屋から通すのが普通なので必要ないということかと思います)

s_IMG_0946[1]

次は、部屋側に戻り、ビニール紐とLANケーブルをしっかりくっつけます。
なるべくCD管の中で引っかかったりしないような形でビニールテープを巻くのがコツです。
そして、風呂場側で紐をひっぱります。CD管は曲げやすいようにヒダヒダの構造になっており、かつ、壁の中をくねくね曲がって伸びていますので、引っかかりやすいです。結構力を入れて引っ張る必要があります。ケーブルとビニール紐の接着がとても重要です。

s_IMG_0947[1]

そしてケーブル開通!
ここまでくれば全工程の9割終了です。
掃除機かついで脚立に登ったり、部屋と天井裏を往復することになりますので(ケーブルがよれるので紐を引っ張る&ケーブルを直すの繰り返し)ここまでの作業が結構時間がかかります。これ以降の作業は慣れていれば10分程度です。

s_IMG_0952[1]

天井裏側はスイッチングハブに接続しますので、普通にコネクタをケーブルに圧着します。
コネクタの圧着は、慣れると100%成功するようになるんですが、最初のうちは失敗もあると思いますので、コネクタ数は余裕をもって用意した方がいいでしょう。失敗した場合はケーブル部分を切断して新たなコネクタでやり直しです。

s_IMG_0954[1]

部屋側の壁埋め込みモジュラーは、色の見本通りに内部の各線を挟みこめばいいだけです。
ケーブル自作した経験のある人は結構多いと思いますが(社内LANとか、データセンター勤務の人とか)、コンセント埋め込みはあまり経験ないと思いますので、構造とか成功率(一個1000円しますし)で不安になる方もいるかと思いますが、結線はやり直せますので心配ないかと思います。あとJIS規格で統一されていますので、コンセントカバーなどの構造に合うかどうかを心配する必要もありません。

この状態で、接続テストを行います。
この手のケーブルを頻繁に自作する仕事をする場合はケーブルチェッカーを使うので簡単にテストできるのですが、そんなの家庭にはありませんので、実際にPCに接続して確認しましょう。
疎通しない場合は、コネクタ側かモジュラー側のどちらかの結線ミスです。

s_IMG_0955[1]

そして、マウンター(っていうのかな)に取り付け壁に取り付けます。
施工業者が、CD管を使う前提のカバーにしてくれていれば良いのですが、場合によってはカバーの変更が必要になるかもしれません。(LANを通す部分に穴が開いてないとか)ホームセンターに売ってます。

s_IMG_0956[1]

カバーを取り付けて
完成!

1000BASE-Tが陳腐化するまで後何年あるか分かりませんが、それまでの間しばらくはこれで快適です。

EC2でRedisを使う場合はHVM

以前、こんな記事を書いたんですが、

RedisがDisk書き込みのタイミングで接続出来なくなる
Redisの処理能力の限界

解決しました。
EC2にr3インスタンスが追加された際に、仮想化方式がHVMしか選択出来なかったので、HVMで起動してRedisサーバにしたのですが、上記問題のどちらも解決しました。

公式ドキュメントにXenとの相性が悪い旨は書いてあったので、前からEC2でのパフォーマンスが悪いことは知っていたのですが、r3インスタンスへのリプレースでHVMになることで、解決してしまいました。

xargsでマルチプロセス

単純にマルチプロセスで実行したいバッチがあった場合
シェルスクリプトから一件づつバックグラウンドで実行したりしてたのですが
バックグラウンド実行だとGearmandでうまく動かないので、何か方法ないかと調べたら
下記のようなシンプルな方法で出来たのでメモ。

これで、namelist.txtの1行ごと、4プロセスづつ実行されます。
-I % でnamelist.txtの1行の文字列が取得出来ます。

RedisのSlaveはMasterよりも容量を大きくした方がよさそう

結論から先に書くと、
RedisのSlaveは、Masterよりも容量を大きくとった方がいい。
理由は、同一容量だと、Masterが容量をフルで使っている場合、このマスターデータ全てをSlaveにSETすることが出来ないから。

主な設定は、
maxmemory 2gb
maxmemory-policy allkeys-lru

症状
Masterがこの容量をフルに使ってる場合、新たにSlaveが同期を開始すると、途中で同期が止まる。
再現性は100%
最初は、Masterのclient-output-buffer-limitで切られていることを疑ったが違った。
おそらく全ての同期を完了する前に、Slaveの容量がいっぱいになってしまっている模様。
このレプリケーションではallkeys-lruの挙動になっていないらしく、新しめのデータがSETされていないことが多い。
ログでは正常に終了した形になっている。

Master
db0:keys=8942214,expires=8778923

Slave
master_link_status:up
db0:keys=8309380,expires=8176889

こんな形で、Slaveとして正常に動いているが、データには差異が出来てしまっている。
Slaveの容量を少しMasterよりも大きくすることで解決。

Cのブリッジライブラリからテーブルを受け取る

今まで、lua_pushstringして文字列を取得する形でしか使って来なかったのですが、テーブルを受け取りたくなったのでやってみました。

これでこんな感じで取れる

[“aaa”,”aaa”,”aaa”,”aaa”]

Cからluaにテーブル渡せるということは、いろいろCで実装出来るので便利。

hiredis使ってみた

luaでresty.redis使ってるんですが、どうも安定しないのでhiredisを使おうと思う。
まずはhsetとhgetallのサンプル書いて動作確認してみた。

$ ./a.out
hgetall: aaaa
hkey: bbbb, value: 1111

RedisがDisk書き込みのタイミングで接続出来なくなる

Redisはデフォルトで定期的にDiskへバックアップをとるようになっていますが、
このタイミングでクライアントからRedisに対して接続出来なくなるようです。

僅かな差分であれば、一瞬で終るのですが、
それなりの更新があると書き込みにかかる時間も増えるのでその間、ずっと繋がらなくなります。

マニュアルには、

BGSAVE()
データベースの保存をバックグラウンドで行います。 OK コードは直ちに返って来ます。Redisはフォークし、親のプロセスはクライアントに対して処理をし続け、子のプロセスはデータベースをディスクに保存したあと死にます。クライアントから保存が無事に終わったかを LASTSAVE コマンドを使って確認することが出来ます。

とあるので、疑問だったのですが、
親プロセスが処理を「受け」続けるとは書いていないので、間違ってはいないのかな。

ということで、Disk書き込みを無効にして、スレーブの方でDisk保存するようにしました。
もし再起動などの際に、Diskに保存したい場合は、BGSAVE()を手動で発行すればOK。