Hitachi HDP725050GLA360

Hitachi HDP725050GLA360
Sequential Read : 87.491 MB/s
Sequential Write : 74.314 MB/s
Random Read 512KB : 37.929 MB/s
Random Write 512KB : 48.406 MB/s
Random Read 4KB : 0.486 MB/s
Random Write 4KB : 1.253 MB/s

Test Size : 100 MB

ラミーのピュアを買った

lamy_pureノブレスのボールペンを紛失して数カ月経ってしまったので,新しいボールペンを何かと思ってラミーのピュアというボールペンを買った。素晴らしい。

LAMY pur

ゆうパックの料金は切手で支払えるらしい

ゆうパックを利用して品物を発送するときに,ゆうパックの伝票と一緒に切手を荷物に貼り付けておけばその分を郵便料金から差し引いて発送することができる(※ゆうパック伝票に切手は貼ってはいけないので荷物に直接貼るように)。当然,切手を大量に持っている人は現金支払いをせずに切手のみでゆうパックを発送することができる。知らなかった。
ゆうパック切手払い – Yahoo!知恵袋

また,ゆうパックの元払いだけはなく,着払いでも切手で配送料金を支払うことが可能であるとのこと。元払いができるのなら着払いでも支払えることに不思議はないが,切手は貼ってはじめてその意味を持つのだとか勝手に思い込んでいたため,品物を受け取り時に切手を手渡して料金を精算するイメージが沸かなかった。切手がこれからはお金に見えてくる。
ゆうパック着払いの切手支払い – Yahoo!知恵袋

あと,いらなくなった年賀状はがきについて。余って使い道がなくなった年賀はがきはゴミでしかないと思っていたが,手数料1枚につき5円を支払うことで切手に交換をしてくれる模様。書き損じのはがきも同様。私は郵便に関してかなり情弱だったことを思い知らされた。失敗したはがきはもったいないことをしたとため息つきながら破って捨ててたけど,何してんの俺。
余った年賀状ハガキは、切手と交換できるのでしょうか? – Yahoo!知恵袋

それにしても郵便局強い・・・。

ハッピープログラムが必死

happy-pgまったく使っていなかったイーバンク銀行に久しぶりにログインしようとしたらハッピープログラムなるものに露骨に登録させようとする画面が表示されるようになっていた。

ハッピープログラムなにそれこわいと思って調べてみると,楽天の会員IDと結び付けて登録することで預金額に応じて特典が受けられるものらしい。会員ステージと呼ばれるランク分けによって,最高で振り込み手数料が7回無料や楽天のポイントアップなどが受けることができ,わかりやすく例えるとトランプの大富豪のランクに似ている。また,獲得レベルなるものも設定されていてそれを合計してランクが決定する模様。かなり複雑なシステムになっているような印象を受ける。
ちなみに,私のイーバンク銀行の預金額では大貧民ビギナーになるらしい。

で,結局はハッピープログラムに登録することはやめておくことにした。根拠はないが,なんとなく直感であまり印象が良くない。このランクシステムやポイントアップなどのシステムがゲーム的というかエンタテイメント的というか,ある種公的な部分も帯びる銀行の企画にしては軽すぎる。とりあえずは何もせずに様子見。ビギナーだけど。

mysqlの運用時のトラブルと試行錯誤のメモ

条件

  • 1分間にクエリの実行が30回〜60回程度発生する。
  • 結果のテーブルは7フィールドの数千〜10万件レコード程度のテーブル
  • mysqlのスペックはCPUがcore2duo,メモリが8GB,他のサービスとしては主にapacheやphp,tomcatなどを同時稼働

結果

  • クエリの結果が表示されない。(メモリが足らない?または、クエリのキャッシュが不具合?)
  • mysqlのサービスは落ちていない。

考察

クエリの実行回数が少ない時は発生しなかったが、高負荷時にはクエリの実行結果が正しく表示されないという現象が頻発するようになった。サービスが落ちてはいないことからキャッシュ関係の設定(table_cache, query_cache_size, max_connections, thread_cache)を見直しながら試行錯誤してみたものの改善せずまた原因もわからず。

メモリを増やせば解決する問題のような、そうでもないような・・・。今で限界の8GB積んでいるから、増やすとなると次は・・・16GB?ECC機能付きのメモリは今の相場だと厳しい値段がついているような予感。それも4GB×4枚だとちょっと。

今のところは応急処置として、定期的にキャッシュクリアをすればなんとか正常にクエリ結果を返すことはわかった。しばらくはそれでもたせて、何か他に見落とした設定があるかもしれないので引き続き調査を続行。

追記

  • キャッシュクリアでは効果があまりない模様。仕方が無いので定期的にmysqlのデーモンをリスタートさせることでさらに応急処置。
  • mysqlの起動スクリプトで簡単にリスタートできることを今更ながら発見。スクリプトの場所は標準なら code>/usr/local/mysql/share/mysql/mysql.server にある。起動スクリプトの使い方は,半角スペースを空けてrestartと入力するばいい。(例:/usr/local/mysql/share/mysql/mysql.server restart)
  • このときオプションもついでに使うことができる模様。オプションを指定して起動スクリプトを実行すると設定ファイルより優先される。(例:/usr/local/mysql/share/mysql/mysql.server restart --skip-slave-start)

追記2

事態が好転しないのでmysqlの設定をもう一度見直し。

  • table_cacheの値を100→1024に大幅に増加して設定してみる。
  • key_bufferの値は控えめに1024MB→256MBに設定してみる。
  • max_connectionsも100→50に減らしてみる。
  • query_cache_sizeの値も16MB→8MBに減らす。

このあたりの設定変更をして様子をみてみる。というか,根本的に何か間違っている予感・・・。

追記3

さらに設定見直し。今度はプログラムの方にも修正を入れることにした。雑に書いていたコード部分を整備して,変数宣言など余計なものをチェックして修正することで少しでもメモリの浪費を抑える。

で,今のところはかろうじて安定してきた。

DDR2メモリの値段がどんどん値上がりしている件

mem-1パソコンパーツなどの通販サイトドスパラでたまにメモリの値段をチェックしていたのだけれど,ここ数週間のうちにとうとう5000円を突破するようになってきた。デスクトップ用のメモリDDR2の2GBで今年の1~2月ごろは4000円ぐらいだったはずで,前は半額くらいの値段だったんだよなと渋々購入した記憶があるのだけれど,今見たらさらに値上がっている。どこまで上がるのやら。

SSL対応とSSL非対応

SSLとは簡単に言うと通信時の内容を暗号化するネットワークの通信手段。これにより第三者に通信内容を傍受されたとしても、暗号化されているためどのような内容か解読することが困難になる。ECサイト利用時にクレジットカードの情報や暗証番号などを送信する場合にはセキュリティ強化という点から導入されることが多くなっている。

利用者としては、何が違うのかは今ひとつわからない。いっそのこと全ての通信はSSLに対応するという指針でも出してSSL非対応は禁止ぐらいにすればいいんじゃないかと思ったが、意味はないか。そうなったらそうなったでさらにセキュリティが強化されたSSSL(Super Secure Sockets Layer)が登場することになり同じことを繰り返すだけになりそうだ。誰得という点を考えればすぐわかることだった。