iisのアクセスログのtimeって開始時間か終了時間か？
ASP.NET Webforms アプリがあるのだが、このごろピーク時の性能劣化がひどくなってるとのことで、Zabbixでリソース監視したり、アクセスログなんかをBigQueryに突っ込んで原因を探ったりしていたのだが、iisのログのtime って、そもそも開始時間なのか、処理の終了時間なのかが気になった。
iisのログには、time-taken という処理時間（ミリ秒）が出力されるが、timeが、開始時間なのか、終了時間なのかでログの見方は変わってくる。
microsoftのサイトを見ると
とあるので、リクエストの開始時刻と思われるが、なんか腑に落ちないのでテストしてみた。
環境
OS：Windows2012R2 サーバ
iisバージョン：8.5
ログ形式 ：W3C
テスト方法
１．めっちゃ重いタイムアウトになる処理を投げる
２．アクセスログでどう記録されるか確認する。
今回は、17:10に処理を開始し、17:31にタイムアウトが発生した。
で、結果。
time：17:31
処理が終わった時間やん！
設定でここの挙動変えれるの？
というわけで、ちょっとハマった話。
iPhoneアプリを独学で作るまで（継続中）
会社のシステムでiPhoneアプリを作ることになりそう
うちはしがないアパレル中堅企業なのだが、店頭用のシステムのリプレースにおいて、iPhoneアプリで作ることになりそう。
んでもって、そんなノウハウ無いので、開発会社の言いなりになるのは嫌だし、何より新しい言語勉強したい欲があったので、自分で勉強することにした。
最終目標としてはアプリをリリースするところまで。（アプリの内容は問わない！）
その経緯を現在進行系で書いていく。
2017年8月「絶対に挫折しないiPhoneアプリ開発「超」入門」を読む
https://www.amazon.co.jp/dp/B01MQPA946www.amazon.co.jp
今から勉強するならswiftだし、ということで、swift3に対応してて、人気が高そうな書籍を漁ったところ、この本にした。
８月に入って、仕事が暇になってきたので、仕事から帰って１、２時間で、50ページ程度を進めてめていく。
最初は、Xcodeの使い方がわけわからんかったが、この本が懇切丁寧なのもあって、なんとなーく理解できた。
swiftの言語についても、デリゲートを覗いては、書いて有ることはほぼ理解できた。（初心者向けだから当然か）
ただ、UIKitとかのiOSのフレームワーク周りが全くの謎。
こういう画面を作りたい時に、どういうクラスを使うのか、どういう書き方でやるのかが全く謎。
最後のアプリもなんとなく書いて動いたけど、その点が理解できず。。。Visual Studioだと、フォームにコンポーネントをペタペタ貼ってけば、アプリができるが、それと同じように頭の中でイメージ化することができない。
これは、色んなアプリを作ってみて、iOSのコンポーネントやそのお作法を学習する必要があるのだろうなー、と思ってみたものの、そういう２冊目に、適した本が見つからない・・・。とりあえず、何か探してみるか。
ただ、アプリ作成→そこで使った言語仕様やXcode、iOSの機能の説明。というサイクルで手を動かしながら学ぶ形式は名前の通り挫折しにくい構成であり、評判どおりかなり良い書籍だと思った。
なお、メリカリで1500円で売れた。
2017年9月「TECHNICAL MASTER はじめてのiOSアプリ開発」を読む
２冊めの本を色々迷った挙句、こちらを購入する。
理由は、１冊目でようわからんと感じたUIKit周りの説明がされていると目次から読み取れたのと、一つのアプリに機能を徐々に追加していくという実用的な流れだったから。
というわけで、本やり終わったらまた追記するぜ
zabbixのデータが増えすぎ問題
去年、監視のために導入したzabbix（ver2.4）ですが、対象サーバが、１２０台くらいあり、テンプレートの監視項目をそのまんま適用してたら、高負荷状態になり、画面ももっさり、監視ももっさりしてきてしまった。
導入後に、zabbixサーバ自体のメンテを怠ってたのは知っていて、いつか対応しなきゃね。って話を、導入した協力会社の人としてたんだが、その人がいなくなってしまい、対応できるのが他におらず、対応することに。
STEP1. 監視項目の見直し
まず、アイテム（監視項目）の減少。
テンプレートの監視項目をすべて適用しているので、一旦、最低限必要なものを覗いて、監視項目を無効化してまわる。
最低限必要なものとは、PING監視と、ディスク容量監視と、アプリケーションログの監視。
3600ほどあった有効な監視項目を1600ほどに削減。（有効になってても実際に監視に使ってない項目もある）
STEP2. データ容量の見直し
過去データを削除するが、対象テーブルの特定。
サイズを調べてみる。（こちらの記事を参考：データベースとテーブルのサイズを確認する方法 - ふってもハレても）
| table_name | engine | tbl_rows | rlen | allMB | dMB | iMB |
|---|---|---|---|---|---|---|
| history_uint | InnoDB | 136449572 | 74 | 14039 | 9748 | 4291 |
| history | InnoDB | 17177763 | 69 | 1734 | 1131 | 603 |
| trends_uint | InnoDB | 14692072 | 80 | 1134 | 1134 | 0 |
| events | InnoDB | 3087769 | 72 | 444 | 212 | 232 |
| history_log | InnoDB | 700203 | 202 | 173 | 135 | 38 |
| trends | InnoDB | 2045698 | 74 | 146 | 146 | 0 |
hisutory_uintの1.3億レコードにびびるが、色々、サイトを見て回ると、データを圧縮しつつ、データファイルをテーブルごとに分割すると良いよとのこと。 mysqlのバージョン的にも適合するので、これでいくことに。
httpd、zabbix-server、mysqldのサービスを止めて、my.cnfを書き換える。
/etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
character-set-server=utf8
#ここから追加
ignore-builtin-innodb
plugin-load=innodb=ha_innodb_plugin.so;innodb_trx=ha_innodb_plugin.so;innodb_locks=ha_innodb_plugin.so;innodb_lock_waits=ha_innodb_plugin.so;innodb_cmp=ha_innodb_plugin.so;innodb_cmp_reset=ha_innodb_plugin.so;innodb_cmpmem=ha_innodb_plugin.so;innodb_cmpmem_reset=ha_innodb_plugin.so
innodb_file_per_table
innodb_file_format=Barracuda
#ここまで
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
mysql起動し、alter tableで対象のテーブルを再構成していく。
history_uintは、でかいので後回しに。
alter table
alter table history ENGINE=INNODB ROW_FORMAT=Compressed;
alter table trends ENGINE=INNODB ROW_FORMAT=Compressed;
alter table trends_uint ENGINE=INNODB ROW_FORMAT=Compressed;
alter table history_log ENGINE=INNODB ROW_FORMAT=Compressed;
alter table events ENGINE=INNODB ROW_FORMAT=Compressed;
再度、データサイズをチェック
| table_name | engine | tbl_rows | rlen | allMB | dMB | iMB |
|---|---|---|---|---|---|---|
| history_uint | InnoDB | 156635215 | 65 | 14047 | 9751 | 4296 |
| history | InnoDB | 16962930 | 33 | 774 | 534 | 239 |
| trends_uint | InnoDB | 15694129 | 34 | 523 | 523 | 0 |
| events | InnoDB | 3073469 | 31 | 204 | 92 | 111 |
| history_log | InnoDB | 746147 | 94 | 86 | 67 | 18 |
| trends | InnoDB | 1963177 | 37 | 69 | 69 | 0 |
データファイルが別ファイルになっているか確認
ls -lh /var/lib/mysql/zabbix/*.ibd
-rw-rw---- 1 mysql mysql 212M 7月 24 15:21 2017 /var/lib/mysql/zabbix/events.ibd
-rw-rw---- 1 mysql mysql 792M 7月 24 15:21 2017 /var/lib/mysql/zabbix/history.ibd
-rw-rw---- 1 mysql mysql 92M 7月 24 15:21 2017 /var/lib/mysql/zabbix/history_log.ibd
-rw-rw---- 1 mysql mysql 64K 7月 24 15:57 2017 /var/lib/mysql/zabbix/history_uint_new.ibd
-rw-rw---- 1 mysql mysql 76M 7月 24 15:21 2017 /var/lib/mysql/zabbix/trends.ibd
-rw-rw---- 1 mysql mysql 536M 7月 24 15:21 2017 /var/lib/mysql/zabbix/trends_uint.ibd
大体サイズは半分になってる。 しかし、最大のテーブル、history_uintがやっかい。なにせ1.5億レコード。
えい、ままよやってまえ！
alter table history_uint ENGINE=INNODB ROW_FORMAT=Compressed;
週末流しっぱにしてたが、60時間たってもSQL終わらず。。。 あえなくKILL。こりゃtruncateしちゃうか。と考えるが、英語のサイトで、別テーブル作成して、任意の期間のデータをコピーして、リネームする手順が紹介されてた。
CLEANING UP THE ZABBIX DATABASE
CREATE TABLE history_uint_new LIKE history_uint;
INSERT INTO history_uint_new SELECT * FROM history_uint WHERE clock > '[timestamp]';
20日間ほどのデータを退避しようとしたが、そもそもSELECTが終わらねえ。うーん。 なので、空のテーブルのまま、TABLEを切り替えることに。（意味なし）
table 切り替え。再度、zabbixを起動して、問題なければDrop table実行
ALTER TABLE history_uint RENAME history_uint_old;
ALTER TABLE history_uint_new RENAME history_uint;
DROP TABLE history_uint_old;
で、３週間くらいたった。
| table_name | engine | tbl_rows | rlen | allMB | dMB | iMB |
|---|---|---|---|---|---|---|
| history_uint | InnoDB | 37300965 | 28 | 1496 | 997 | 499 |
| trends_uint | InnoDB | 14785949 | 36 | 509 | 509 | 0 |
| history | InnoDB | 7749555 | 40 | 423 | 299 | 124 |
| events | InnoDB | 2530589 | 31 | 172 | 76 | 95 |
| trends | InnoDB | 1704568 | 36 | 59 | 59 | 0 |
| history_log | InnoDB | 339517 | 102 | 43 | 33 | 10 |
サイズは、対応前の15%程度。 大丈夫そうなので、必要なサーバに関しては、リソース系の監視項目を追加しようと考え中。
