昨日WindowsUpdateを確認してみたら、ようやくCF-SX1のWindows10への無料アップグレードの準備が完了していた。
以前CF-S10をアップグレードした時には待ちきれずに、DVDにダウンロードしたものをアップグレードしたのでノートPCでは自然にダウンロードを待っているとこれだけ時間がかかるのか？
デスクトップPCの場合はほぼ2日ぐらいでアップグレードの準備（ダウンロード）が完了したのだが、WIFIだから遅いのか？はたまた運なのか？
Let’s noteでWindows10が公式サポートされているのはCF-SXシリーズではCF-SX3からなのだが、
互換性をみるとBluetoothモジュール以外はOKっぽい。
今夜にでもアップグレードしてみるかな！
後日アップデートしました。
CF-SX1 Windows10アップグレード
月末になると有効期限の迫ったクーポンを消耗すべく、高速クーポンをONのまま使うことが多いのだが、最近突然ネットが詰まるケースが目につく。
以前は高速モードにしていて不満など感じなかったのだが、今では高速モードで詰まるぐらいなら最初からクーポンOFFで使うワイ！と思っているほどである。
特にSSHで作業をしているときに、フリーズしたようにキー入力が効かなくなるのがいただけない！
Webの閲覧であれば、バックグラウンドで流しているので良いのだが、SSH作業はメイン作業だから止まってしまうと困るのである。
自宅付近では低速モードでも十分SSHできたのは以前の記事の通りなので、やはり地下鉄の車内という混雑状況の影響であることは間違いないだろう。
ここ10か月ほどAWSと戯れているが、起動しているインスタンスが多いほど、EC2のインスタンスのメンテナンスにあたってしまうことが多い。
特に今月から来月にかけてが多くて、一気に6インスタンスも対応した。
ただインスタンス障害といっても、期限が一か月ぐらい先の場合は該当インスタンスはまだ起動しており接続可能。おそらくこれは通常のハードウェアメンテナンスと同様で予定されたものだろう。
それに対して、期限が数日後のような場合は、AWSから連絡が来たときにはすでに該当インスタンスに接続できなくなっているケースがほとんど。この場合停止させるのも一苦労で強制停止を何回か繰り返した後、数時間たってようやく停止するというケースもある。
停止しているインスタンスは関係ないので、不要なら停止しておくこと。
本日自分のバックアップディスクをiso化して、再整理プロジェクトをスタートした。
DVD-Rではあまり読み込めないという事態に陥ったことはないのだが、DVD-RAMのディスクが認識せず焦る。
以前にもこのディスクは書き込んだマシンでは読み込めるが、それ以外のマシンでは不安定になるという現象があったので、書き込んだマシンで再び読み込んでみるか！
それでも駄目だったら、信頼性に難ありなので金輪際DVD-RAMは利用しない！ということで！
最近のPCは光学ドライブがついていないものが多いので、
自分のバックアップ用DVDをFree DVD ISO Makerでiso化してローカルに保存している。
しかし今日Free DVD ISO Makerを起動したらregistration codeなる画面が出るようになってしまい先に進まない。
これではFreeの名折れというわけで、速効代替製品を探す。
ISO Workshopというソフトが吸い出しも書き込みもできるので良いみたい。
さっそくインストールして使ってみた。
インストール時にカスタムを選んで余計なソフトが入らないようにしておく。
今までSATA2.0の速度で満足していたのだが、最近の新しいSATAの規格では桁違いの速さが出るらしい。
まずMSATAの後継となるM.2。転送速度は10Gb/s。
PCI Express接続と従来のSATA接続の二つがあり、PCI Express接続でないと速度が出ないので注意。
実際のベンチマークを見ると500MB/s→770MB/sぐらいなので体感はないだろうけど。
インテルの最新のチップセットだと32Gb/sにまで速度が出るらしい！
ただしネットを調べる限りだとSATA接続のSSDが優勢であり、
PCI Express接続の価格はなんと二倍だ！
$ sudo cp /usr/share/zoneinfo/Japan /etc/localtime
上記コマンド一行！実行するだけなのだが、yum updateのタイミングでUTCに戻ってしまうケースがあるので、戻っていたらまた同じようにコマンドを実施するのみ。
追記：
Windows Azureでも同じようにデフォルトでUTCなので、同じコマンドで対処できる。
AWSにはデフォルトでSWAPがないため、メモリ不足の事態が発生するとOOMKillerが誘発されてプロセスが死んでしまう事態が起こり得る。
SWAPがあれば耐えられる局面も多いので、場当たり的対応だが、SWAPをルートパーティションに作成してしのぐ技。再起動するとなくなるので注意。
dd if=/dev/zero of=/swap bs=1M count=512 chmod 600 /swap mkswap /swap swapon /swap # 確認 swapon -s
再起動後も有効にするには/etc/fstabに以下の一行を追記する。
/swap swap swap defaults 0 0
AWSには1年間の無料利用枠があり、t2.microインスタンスを1つだけ起動している状態であれば、無料枠を超えることはないのだが、EBSのSNAPSHOTを取った場合は料金がかかってくるので注意。
Snapshot取った直後は料金が表示されていなかったのだが、先日は$0.05で、本日は$0.08であった。
どうも月間での平均利用で課金されるのかもしれない。
（大した金額ではないが！）
$0.095 per GB-Month of snapshot data stored – Asia Pacific (Tokyo)
請求書の記載には上記の通りなので、1GBだと月11円程度かな。
いずれにしてもsnapshotの大きさが1GBを超えなければ無料枠の範囲内っぽいが、通常は超えるよな。
というわけでsnapshotをずーと取っておくとわずかながらにお金がかかる。
実験用途であればSnapshotなぞ取らないで、消してしまうのが良いだろう！
テキストファイルでダンプをとれるプログラムはファイルサイズが大きくなりがちなので、出力と同時に圧縮をかけたい場面が多いと思われる。
以下のように記述するとMySQLのDBダンプとりつつそれをgzにすることが一度でできる。
#プレーンテキスト出力 mysqldump -u root -p DB_NAME > /var/tmp/DB_NAME.sql #出力を圧縮する mysqldump -u root -p DB_NAME | gzip > /var/tmp/DB_NAME.sql.gz
svnadmin dump REPO_DIR | 以降の記述は一緒である！
