読者です 読者をやめる 読者になる 読者になる

カメニッキ

カメとインコと釣りの人です

響灘緑地グリーンパークに行ったら、とても良かったので紹介

f:id:tapira:20170212202837j:plain

www.hibikinadagp.org

この辺

f:id:tapira:20170212205437p:plain

料金

  • 入園料: 公園や芝生の広場で遊べるっぽい
    • 大人 100円
    • 小中学生 50円
    • 幼児 無料
  • カンガルー広場
    • 大人 300円
    • 小中学生 150円
  • 熱帯生態園
    • 大人: 300円
    • 小中学生 150円
  • 駐車場 300円

主に今回の紹介は 熱帯生態園カンガルー広場 他にもサイクリングコースやアスレチック、ポニー乗馬体験があった。

熱帯生態園

カンガルー広場

  • わらわらいる f:id:tapira:20170212205148j:plain − 触れる f:id:tapira:20170212205200j:plain

余談

  • オニオオハシは100万円くらいで自宅でも飼えるらしい…。
  • うちのナナイロメキシコインコも可愛い f:id:tapira:20170212205337g:plain

ダイワ 16 リーガル 2004H PE付のインプレ

スペック

  • 巻取り長さ(ハンドル1回転あたり):71cm
  • ギア比:5.3
  • 自重:240g
  • 最大ドラグ力:2kg
  • ハンドル長:45cm
  • 標準糸巻量(ナイロンlb-m):3-140/4-100
  • 標準糸巻量(PE号-m):0.3-150/0.4-120

用途

  • アジング、メバリング他ライトゲーム

感想

  • 標準装備のPEについて、キャスティングは僕が下手なのを差し引いても、使い物にならないレベルだと思う。
  • ライトゲームに高級なリールの必要性があんまりわかってなくて、安価なこのリールでも十分楽しめる(と思う)
  • 巻き心地も滑らかで、何の不満もない
  • 同サイズのカルディアと比較して40g重いけど、元々道具の重さはあんまり気にならないから大丈夫だった
  • 値段からすると見た目も良かった

Amazonで5,000円ちょいで買えるのはとてもよい

追記

あれ????PE捨てるんだったら、同じ値段のレブロス買ったほうが良いのでは・・・・・

九州インフラ交流勉強会(Kixs) Vol.002に参加&発表してきた

kixs.connpass.com

メインフレーム ~ AWSまで幅広い年代の話、非同期通信ネタとNTPで福大に向けるな!っていう話が聞けるイベントは、福岡では数少ないうちの一つだと思いました。

ちなみに僕は今更ISUCONの振り返りをしてきました。 資料作りがバタバタになってしまって、かなりアレでしたが、ISUCONに興味もって下さった人もいて良かった。

スライド

speakerdeck.com

次回はロードバランサーナイトとのことで、来年開催。楽しみ

w3-total-cacheプラグインで、サーバエラーが発生する問題の対処法

これの続き

tapira.hatenablog.com

対処法

結論から言うと w3-total-cacheDatabase Cache 無効化で良い

再現

  1. wordpressインストール
  2. w3-total-cacheプラグインインストール
  3. General Settings にて以下を有効化。他はデフォ値で。
    Page Cache / Database Cache / Object Cache / Browser Cache
  4. 画像を含んだ投稿をおこなう
  5. 管理者ログアウトした状態でトップページ表示

原因(?)

細かく追ってないけど Object Cache が消えているのに、 Database Cache がファイルがあるものとして記憶しているっぽくて No such file or directory の後、無限ループに入り死んでるように見える。(違ったらすいません)

レンサバ何箇所かで試すと再現するけど、プラグインの問題なのだろうか

PHPがsegmentation faultで死ぬ原因を追跡する

発端

WordPressで構築されたサイトで 502 Proxy Error が出る、という問題が発生した。

[LB] -> [Reverse proxy] -> [Webサーバ] という構成のため、ユーザへ返るステータスコードReverse proxy が吐いてる。
ここが 502 Proxy Error となるのは、プロキシした先の Webサーバhttpdプロセスが異常終了してしまっている事が原因だった。

※ちなみに今回PHPのセグフォでhttpdが死んでいるのは、dsoだったため。httpdから生えたcgiだった場合、cgiのセグフォをhttpdが検知できるので、恐らく500エラーを返すことになる

なぜ異常終了しているかを調べた(未解決)


  • httpdのエラーログを見ると、プロセスがセグフォで死んでいることがわかる。
[Wed Nov 30 11:53:51.240210 2016] [core:notice] [pid 16547] AH00052: child pid 18079 exit signal Segmentation fault (11)
  • straceでセグフォで死ぬプログラムをみてみると brk システムコールを呼び続けて最後に死んでた
brk(0x5631000)                          = 0x5631000
brk(0x5671000)                          = 0x5671000
brk(0x56b1000)                          = 0x56b1000
brk(0x56f1000)                          = 0x56f1000
brk(0x5731000)                          = 0x5731000
brk(0x5771000)                          = 0x5771000
brk(0x57b1000)                          = 0x57b1000
brk(0x57f1000)                          = 0x57f1000
brk(0x5831000)                          = 0x5831000
brk(0x5871000)                          = 0x5871000
brk(0x58b1000)                          = 0x58b1000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

brkシステムコール直前 wp-content/cache/object/ とキャッシュを触っており、キャッシュ関連のプラグインが怪しいと目星がついたので、試しにそのプラグインを無効化すると、本問題は発生しなくなった。
プラグイン無効化で終わり、でもいいが、なぜセグフォするのかもう少し調査
- 次にcore dumpを吐かせた

# coreファイルのサイズ制限を外す
$ ulimit -c unlimited
# 確認
$ ulimit -a | grep core
# 問題のコードを実行する
# カレントディレクトリにcoreがはかれる
$ ls -l core.19380
# fileコマンドで何のプログラムでセグフォしたcoreかみれる
$ file core.19380
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, from '/usr/local/php/bin/php-cgi sample.php'
# gdbで解析
$ gdb /usr/local/php/bin/php-cgi -c core.19380
()
Core was generated by `/usr/local/php/bin/php-cgi sample.php'.
Program terminated with signal 11, Segmentation fault.
#0  zend_parse_arg (arg_num=1, arg=0x5e4a6b8, va=0x7ffdbf6cd110, spec=0x7ffdbf6cd0c8, quiet=0, tsrm_ls=0x1b350c0)
    at /tmp/php-build/source/5.6.21/Zend/zend_API.c:686
686 /tmp/php-build/source/5.6.21/Zend/zend_API.c: そのようなファイルやディレクトリはありません.
    in /tmp/php-build/source/5.6.21/Zend/zend_API.c
(略)
(gdb) bt
#0  zend_parse_arg (arg_num=1, arg=0x5e4a6b8, va=0x7ffdbf6cd110, spec=0x7ffdbf6cd0c8, quiet=0, tsrm_ls=0x1b350c0)
    at /tmp/php-build/source/5.6.21/Zend/zend_API.c:686
#1  0x000000000089dec3 in zend_parse_va_args (num_args=<value optimized out>, type_spec=0xa2b863 "s", va=0x7ffdbf6cd110,
    flags=<value optimized out>, tsrm_ls=0x1b350c0) at /tmp/php-build/source/5.6.21/Zend/zend_API.c:873
#2  0x000000000089e7d6 in zend_parse_parameters (num_args=1, tsrm_ls=0x1b350c0, type_spec=<value optimized out>)
    at /tmp/php-build/source/5.6.21/Zend/zend_API.c:924
#3  0x00000000008a8464 in zif_defined (ht=<value optimized out>, return_value=0x5dff408, return_value_ptr=<value optimized out>,
    this_ptr=<value optimized out>, return_value_used=<value optimized out>, tsrm_ls=0x1b350c0)
    at /tmp/php-build/source/5.6.21/Zend/zend_builtin_functions.c:735
#4  0x000000000091bf93 in zend_do_fcall_common_helper_SPEC (execute_data=<value optimized out>, tsrm_ls=0x1b350c0)
    at /tmp/php-build/source/5.6.21/Zend/zend_vm_execute.h:558
#5  0x0000000000909c4b in execute_ex (execute_data=0x5e4a610, tsrm_ls=0x1b350c0)
    at /tmp/php-build/source/5.6.21/Zend/zend_vm_execute.h:363
#6  0x000000000091c44e in zend_do_fcall_common_helper_SPEC (execute_data=<value optimized out>, tsrm_ls=0x1b350c0)
    at /tmp/php-build/source/5.6.21/Zend/zend_vm_execute.h:592
#7  0x0000000000909c4b in execute_ex (execute_data=0x5e4a3d0, tsrm_ls=0x1b350c0)
    at /tmp/php-build/source/5.6.21/Zend/zend_vm_execute.h:363
#8  0x000000000091c44e in zend_do_fcall_common_helper_SPEC (execute_data=<value optimized out>, tsrm_ls=0x1b350c0)
    at /tmp/php-build/source/5.6.21/Zend/zend_vm_execute.h:592
#9  0x0000000000909c4b in execute_ex (execute_data=0x5e49b38, tsrm_ls=0x1b350c0)
    at /tmp/php-build/source/5.6.21/Zend/zend_vm_execute.h:363
#10 0x000000000091c44e in zend_do_fcall_common_helper_SPEC (execute_data=<value optimized out>, tsrm_ls=0x1b350c0)
    at /tmp/php-build/source/5.6.21/Zend/zend_vm_execute.h:592
#11 0x0000000000909c4b in execute_ex (execute_data=0x5e499d0, tsrm_ls=0x1b350c0)
    at /tmp/php-build/source/5.6.21/Zend/zend_vm_execute.h:363
(略)

Zend/zend_vm_execute.h:363行目Zend/zend_vm_execute.h:592行目 が無限につづいていた。
なんでこうなるのかよくわかってない。Zendのバグなんじゃないの?とか思って眺めてた。
また、上記の問題は thread safe版 の場合。試しに同じconfigureオプションで作った non thread safe版 を使用して同じプログラムを実行させると、セグフォはおきなかった。
その代わりに brk システムコールを無限に実行し続けて memory_limit の値に引っかかってた。
試しに1GBほど割り当てても同様に全て食いつぶしてメモリ不足になってたので、やっぱりZendのバグなんじゃないの?とか思ってる。
ここからどうすれば根本的な原因(もしあるならバグの箇所)までたどり着けるのか、調べ方がわからない。勉強しようと思った

追記: 原因と思われるもの

tapira.hatenablog.com