limits.conf の soft / hard について
soft limit / hard limit の理解について曖昧だったので、おさらいしました。
そもそもOSのどこで設定していたんだっけ、というところから。
◇/etc/security/limits.confに関するメモ
http://open-groove.net/linux/memo-etcsecuritylimits-conf/
定義は明快に書いてありました。助かります。
soft/hardの違いは、softが一般ユーザが変更できる上限値で、hardはrootが変更できる
上限値を意味する。ユーザ名を「*」とすればすべてのユーザに適用される。
とのことです。
ユーザごとの設定で soft / hard が記述できるので、sshの接続数制限とかと似て、softは超過しても、hardまではある程度許される猶予なのかと思いましたが、そうではなく、「各ユーザにて、 ログインして ulimit で（一時的な）変更ができる上限値」 = soft であると。
無理やりsshとの関連を挙げるのであれば、上記URLのページの最後にある、
「sshではセキュリティ確保のため、ssh経由で接続したプロセスに対し、そのユーザーが本来持っている権限以上の変更はできない」
というところでしょうか。
ファイルディスクリプタの制限 については、nginx(worker_rlimit_nofile ※プロセスごとの上限)やMySQL(open_files_limit) などミドルウェアで独自に設定値を持っているケースもあるので、頭に入れておくと、トラブルシューティング時の視点が広がると思います。
◇mysqldのファイルディスクリプタ数
http://studio3104.hatenablog.com/entry/20121030/1351587278
エンジニアのためのミスを減らすチェック方法
1年目の新人に、サーバのキー（ハッシュ文字列）20個あまりを ファイルサーバに保管するようお願いしたのですが、 文字列のキーをコピペしてく作業なので、きっと間違いが出ると思い、 他の人にもチェックしてもらったところ、やはりミスがありました。
具体的には、キー文字列が欠けていて、正しくコピペしきれていませんでした、というありがちな話。
本作業としては、間違い自体は検知・修正して正しく保管できれば良いので、 それでこの作業はおしまいなのですが、仕事に慣れてきたせいもあり、 普段、慎重な確認や注意が必要なはずの仕事を少し適当に済ませてしまう傾向があるので、 この後、彼になぜミスったかなどを考えてもらいました。
そうしたら、だいたい以下のような考察と、相談を頂きました。
【質問】
1. チェックの観点
2日に分けて（次の日にもう一度）見直しチェックをしたのに、それでも間違えてしまった。 これはチェックするべき観点を誤っているからではないか？ どんなことに気をつけたら良いのでしょうか？
2. チェック方法
漏れなく誤りを検出できるような良いチェック方法はないでしょうか？
3. 意識の問題
そもそもチェックに対する意識が低いのではという認識がある。 どうしたらもっと意識を高められるでしょうか？
自分の胸に手を当ててしばし考え、そしてだいたい以下のような回答をしました。
【回答】
1. 仮説を立てていない
2回に分けてチェックをしても同じミス（見過ごし）をしてしまったのは、 彼が見直しチェックをする前に、 「どんなミスをしてしまう可能性があるのか」を考えていなかった、 つまり仮説を立てていなかったことに起因しています。 エンジニアの仕事に準えて言えば、テストケースを考えていないとも言えます。
どんなミスが考えられるか、から考えてチェックする箇所を考えれば、 チェック観点ははっきりしますし、集中できます。
但し、新たな仮説を考えず、類似作業を経験すればするほど、 慣れてしまって「思い込み」が強くなり、チェックの観点が狭くなるので注意が必要ですね。
第三者にダブルチェックを行ってもらう理由もここにあります。
2. 機械的な確認方法を考える
- と併用して、これを考える必要があります。 いくら意識を持ってチェックをしても、人間の目でチェックする限りミスは避けられませんし、時間もかかり非効率です。
その点、機械的なチェックができれば、誤りなく効率的に出来ます。
もちろん、最終的に自分の目でも大丈夫かの念押しをする方が良いですが、便利なツールをうまく活用したいところです。
今回新人に行ってもらったのはキー文字列の保存ですから、正しく保存出来ているかを後からチェックするには、WinMerge などのdiff用ツールや、Excelのセル2つに文字列を貼り付けて関数でチェックするなどの方法が便利です。
【Excel関数の例】
=exact (A1,B1)
=if(A1=B1,"OK","NG")
=len(A1)
使い分けとしては、
・ファイルが完全に一致するかの比較 → diffツール
・ログなど、文字列が行ごとに一致するかの比較、桁数の確認 → Excel
こんな感じでしょうか。
言うまでもありませんが、チェック方法（特にExcel自作の場合はロジックなど）が正しいかどうかの検証は大前提なので怠らないこと。
機械的なチェックが難しいもの（例えば出ている画像やレイアウトなど）は目視だけが頼りになるので、横に並べるなどして差異が目に入りやすい、比較しやすい工夫をした上で、指差し確認するしかありません。
3. 間違えたらどんな影響があるのか（どれくらいヤバイのか）を考える
最後はこんな感じですが、でも大事です。
どんな作業でもそうですが、失敗したら、また誤りに気づかなかったら、その後どんなまずいことになってしまうかを考えれば、それだけ真剣にチェックするというものです。
ただこれは大失敗した or 大失敗しそうだった、という経験がないと本当の意味で学べないというのが欠点です。
裏を返すと、経験をすると身に染みて分かるようになります。
なので、失敗して障害を起こすのは決してオススメはしませんが、会社orチームがピンチにならない程度に、失敗はたくさんした方が良いです。
実力のある人は失敗どころか、挫折するほどの経験を持った人ばかりです。
大失敗を経験できるのは貴重なのです。
その代わり、同じ失敗は繰り返さないことが大事です。
大きな失敗をした場合は次はないので、ハイプレッシャーが掛かるようになり意識は最高に上がりますｗ
こんなところでしょうか。
何年も仕事をやっていれば当たり前の事ばかりですが、こうやって整理して教えたことを、後輩がまた後輩に教えてくれればいいなと思います。
【感想】MySQLのパフォーマンスに関する記事を読んで
以下の記事を読んで自分なりに解釈＆所感。
Yakst - MySQLの大きなテーブルでのパフォーマンスを改善する10の方法
1.MyISAMではなくInnoDBを使う。
→MySQLのチューニングとしてはまぁ普通の考え。
「古い時代のアーキテクチャ」とか「ファイルシステムに毛が生えたようなもの」って聞いたし。
が、当然ながら新規構築なら設計時に大前提で考慮することなので、後からチューニングとかって類の考えではない。
2.InnoDBは、ユニークでないセカンダリインデックスを・・・
→つまり5.5以降+InnoDBにバージョンアップしろと。
新しいバージョンにするというアプローチはパフォーマンス改善の考え方としてはありだけど、
チューニングとは言えないかも。
アプリ変更・テストが必要なケースなどが多々あるので優先度は高くできない。
3.パーティショニングは・・・MySQL5.7.2で・・・
→これは知らなかった。ていうかまだリリースされていないし。
新機能を使うというアプローチもチューニングとは言い難いけど。
でも、「パーティション化する」は立派なチューニング。
4.InnoDBの圧縮機能を使う
→圧縮はread/write性能が悪くならないかちょっと心配だけど5.6でかなり良くなったとのウワサ。
Oracleなども圧縮機能はある。
データ縮小によるフルスキャン性能UP ＞ read/write性能down と判断できるなら検討の余地あり。
5.ソートしたデータをバルクロード
→ロード方法を変えて時間を短縮するアプローチもよくやるね。
6.不要なインデックスを消す
→地味に必要。なかなか運用中手をつけにくいけど。
インデックスが多いと更新性能が落ちるので。
7.プライマリキーの種類（データ型）変更
→データ型とデータ長もread性能に響くので、テーブル設計時の重要な要素。
8.新しいテーブルにバルクロードする場合は、PRIMARY KEY以外のインデックスは後で作る。
→大事。
データの一意性が保証されているものをロードするなら、PrimaryKeyですらロード後に作る。
ロード処理をバッチに入れていたりするなら、チューニング（調整）になるが、
どちらかというとお作法（常識）な気がする。
9.メモリを増やせば (ry
→当然ね。
InnoDB＆Readメインならとにかくバッファにどれだけ載せられるかが勝負なので。
10.メモリと同じく、SSDも役に立つ。
→これも。今だとioDriveが選択肢か。
・・・とまぁ、人の書いたもので感想述べただけですが、
設計・運用でパフォーマンスに影響する要素のまとめとして、勉強になりました。
靴紐の通し方
年始の買い物で革靴を買ってきた。
家に帰って箱から出し、靴紐を抜いてイチから通す。やれやれ・・・
ちょっと待て。
いつも思うんだが、なぜ新品の靴の紐はこんなメチャクチャな通し方してあるんだろう？
ディスプレイの都合上？
でもそれにしちゃ、履くときと全然違う通し方をしてあるというのも変な話だ。
もしかして何か意味があるのでは・・・？
いや、そもそも革靴の紐ってどうやって通すのが正しいんだ？
気になったので調べてみよう。Google先生～！
（※この時 1/6 1:00過ぎ。つまり仕事初め前。早く寝るべき。）
靴紐の通し方と呼び方 | 靴のあれこれ | リーガルコーポレーション
・・・これ見てショック。
メチャクチャだと思っていた買ったばかりの革靴の紐は、「シングル」という
れっきとしたビジネスシューズ用の通し方になっていたのか。。
ちなみにここらで薄々気づかれていると思うが、
自分の知っている紐の通し方は、スニーカーの紐を通す時に使う
アンダーラップとオーバーラップだった。
しかも両者の違いはなんとなく見栄えで使い分けていただけで、
名前があることすら分かっていなかったという。。
なんと恥ずかしい。
もう社会に出て何年経つんだ(+。+)
まぁ、今後靴紐を通すのが少し楽しくなってきた。
今回はシングルにしたが、パラレルも今度やってみよう。
新年から一つビジネスファッションの基本を知ることができた2014年のスタートでした。
s3fs と s3cmd
EC2からS3に大量のログファイルを保存するために
・s3fs（正確にはs3fs-c）
・s3cmd
の2種類を使っていたがどちらも一長一短という感じで、悩みが。
【それぞれの特徴】
・s3fs
（長所）ファイルシステムとしてマウントしローカルファイルのようにcpなどの操作が可能
（短所）メモリリーク（swapが激しい）←ホントにイタイ
・s3cmd
（長所）S3の操作の多くがコマンドラインで出来る
（短所）pythonのメモリ消費量多め、数GBサイズの大きいファイルの操作（後述）
長所としてはどちらも良い所があるのだが、s3fsの短所：メモリリークがどうにも許容できず、
s3cmd一本で行こうと思い始めたところ、数GB級のファイルをS3にputしようとして下記エラー。
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
An unexpected error has occurred.
Please report the following lines to:
s3tools-bugs@lists.sourceforge.net
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Problem: KeyError: 'size'
S3cmd: 1.1.0-beta2
Traceback (most recent call last):
File "/usr/local/s3cmd/s3cmd", line 1804, in
main()
File "/usr/local/s3cmd/s3cmd", line 1745, in main
cmd_func(args)
File "/usr/local/s3cmd/s3cmd", line 969, in cmd_sync
return cmd_sync_local2remote(args)
File "/usr/local/s3cmd/s3cmd", line 936, in cmd_sync_local2remote
(item['full_name_unicode'], uri, response["size"], response["elapsed"],
KeyError: 'size'
’size’と出ていたものの何が悪いのかはっきりとは分からなかっただが、
幾つかのファイルを試して、ファイルサイズが問題だということに。
どうにもならないのかぁぁと諦めかけたものの、よーくヘルプを見てみると、
以下のようなオプションが。
--multipart-chunk-size-mb=xx(MB)
どうやら、5GB以上の大きいファイルをアップする場合、このオプションが無いとエラーになるらしい。
↓ こちらにわかりやすい解説があった。
cloudpackブログ: s3cmdでmultipartオプションを利用してs3へアップロード
ということで、以下のように指定。
s3cmd put --multipart-chunk-size-mb=5120 転送するファイル s3://バケット名/オブジェクトパス
これでうまくアップ出来るようになった。
良かった。
以下も分かりやすく、参考になった。
s3cmdで5GB以上のファイルをS３にアップロードする方法 - 雑多なインフラエンジニア日記
