タグ別アーカイブ: osx

osx brew で easy_install が正常にインストールされない

概要

python を使用する機会があり、brew経由でインストールを行った。
ついで pip をインストールしようとしたところ下記のようなエラーがでてしまって pip のインストールができない。
これについて対応してみる。

$ easy_install
Traceback (most recent call last):
  File "/usr/local/bin/easy_install", line 9, in <module>
    load_entry_point('setuptools==29.0.1', 'console_scripts', 'easy_install')()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 357, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 2394, in load_entry_point
    return ep.load()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 2108, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "build/bdist.macosx-10.11-intel/egg/setuptools/__init__.py", line 10, in <module>
  File "build/bdist.macosx-10.11-intel/egg/setuptools/extern/__init__.py", line 1, in <module>
ImportError: No module named extern

調査する

brew を用いてインストールしたのだが、一度消してまた入れてみる

$ brew install python
==&gt; Downloading https://homebrew.bintray.com/bottles/python-2.7.12_2.el_capitan.bottle.tar.gz
Already downloaded: .../Caches/Homebrew/python-2.7.12_2.el_capitan.bottle.tar.gz
==&gt; Pouring python-2.7.12_2.el_capitan.bottle.tar.gz
==&gt; Using the sandbox
Warning: The post-install step did not complete successfully
You can try again using <code>brew postinstall python</code>
==&gt; Caveats
Pip and setuptools have been installed. To update them
  pip install --upgrade pip setuptools

You can install Python packages with
  pip install &lt;package&gt;

They will install into the site-package directory
  /usr/local/lib/python2.7/site-packages

See: https://github.com/Homebrew/brew/blob/master/docs/Homebrew-and-Python.md

.app bundles were installed.
Run <code>brew linkapps python</code> to symlink these to /Applications.
==&gt; Summary
🍺  /usr/local/Cellar/python/2.7.12_2: 2,948 files, 39.8M

すると読み飛ばしていたのだがインストール後の処理が正常に完了していないようなことが表示されていた。

手動で実行してみると

$ brew postinstall python
==> Using the sandbox
Error: Permission denied - /usr/local/lib/python2.7/site-packages/sitecustomize.py20161201-35997-9nuclf

すると権限がないようなことを言われる。これが原因か?

対応

brew は sudo で実行することはできないので(詳しくないができるかも。できても推奨していないが。)
権限で文句を言われている lib/python2.7 に直接一般ユーザでの権限を与える

$ sudo chown -R <user>:<group> /usr/local/lib/python2.7

そして再度後処理を実行してみる

$ brew postinstall python
==> Using the sandbox
==> /usr/local/Cellar/python/2.7.12_2/bin/python -s setup.py --no-user-cfg install --force --verbose
==> /usr/local/Cellar/python/2.7.12_2/bin/python -s setup.py --no-user-cfg install --force --verbose
==> /usr/local/Cellar/python/2.7.12_2/bin/python -s setup.py --no-user-cfg install --force --verbose

原因はよくわからないが動いた。easy_installも動作することが確認できました。
なんてことはありませんでした。


mac osx におけるファイルディスクリプタの上限

概要

mac osxでmysql5.7.11を用いてアプリケーション開発を行ったところ、特定の動作をした時点でアプリケーションが動作しなくなる現象に直面した。

mysqlのエラーログを確認してみると下記のようなエラーが出ていることが確認できた。

[Warning] File Descriptor 2032 exceedeed FD_SETSIZE=1024

開発にともなって行った「特定の動作」とはmysqlにおいて、あるテーブルにpartitioningを適用したことである。それも結構な数の。
なるほどmysqlエラーログと合わせてみてみるとその状況は察することができる。
partitioningを切ったことで、物理的に異なるファイルとしてその実態データファイル(InnoDBでいうところのibdファイル)が分離された。
mysql上でそれら実体ファイルをオープンしているfile descriptorがosの上限を上回ったのであろう。

この点について原因の調査と、対応方法をまとめる。

検証

さて、ここでアプリケーション上で起こった問題を再現して、再度その問題が憶測と合っているか検証してみよう。

ここで、sqlを作成する簡単なphpプログラムを用意する。
余談だがやっぱ私の年代となるとスクリプトももっぱらphpだな。

テーブルを作成するsqlを生成するphpコード

下記のコードを実行することで、3000個のパーティショニングを日付で切ったテーブルを作成する
ちなみに、paritioningの最後のところでカンマが一つ多くなるので注意されたし。
そのまま実行する場合は構文エラーになるので手動で削除してください。

<?php
date_default_timezone_set('Asia/Tokyo');

$pivot = strtotime('2010-01-01 00:00:00');
create_partition($pivot);

// create partition ddl
function create_partition($date){
	echo "CREATE TABLE t (id BIGINT auto_increment, name VARCHAR(50), purchased DATE, primary key(id, purchased)) ENGINE=InnoDB DEFAULT charset=utf8 PARTITION BY RANGE COLUMNS(purchased) (";
	for($i=0; $i<3000; $i++) {
		echo "PARTITION p{$i} VALUES LESS THAN ('" . date('Y-m-d', $date) . "')," . PHP_EOL;
		$date = strtotime(date('Y-m-d H:i:s', $date) . " +1 days");
	}
	echo ");";
}

データを挿入するsqlを生成するphpコード

続いて各パーティションにデータを挿入してみる。
下記のコードを実行する。

<?php
date_default_timezone_set('Asia/Tokyo');

$pivot = strtotime('2010-01-01 00:00:00');
create_data($pivot);

// insert data
function create_data($date){
	for($i=0; $i<2999; $i++) {
		echo "INSERT INTO t(name, purchased) VALUES('name{$i}', '" . date('Y-m-d H:i:s', $date) . "');" . PHP_EOL;
		$date = strtotime(date('Y-m-d H:i:s', $date) . " +1 days");
	}
}

そしてその状態で再度mysqlへ接続し、use文を用いてデータベースを選択すると

[Warning] File Descriptor 2032 exceedeed FD_SETSIZE=1024

再現した。

調査

原因は概ね特定できたので、この件について対応方法がないかweb上で検索する。

するとピタリ。こちらのmysqlのバグレポートに全く同じ事象が報告されている。

詳しくは上記のリンクに目を通していただけるとよい。
要約すると osx 固有のバグであり、予想していたように FD_SETSIZE が os の規定値を上回っているためである。
また、するとこの os が持っているファイルディスクリプタの上限値を変更できないのか?
ということを想像するが、残念ながらこれは mac osx で動作している現在の mysql5.7.11 では不可能である。

というのもこちらの github コードを参照してもらうとわかるように osx では FD_SETSIZE 決め打ちで上限を規定している。
これを回避するためには自分でソースコードを改修し、リビルドするしかない。

対応

では、この問題に対応できないのか?というと、そういうわけでもない。
別のアプローチで対処する事が可能である。

問題は mysql がテーブルを参照する際にオープンしている file descriptor の数が多すぎることである。
mysql アプリケーションのパラメータを変更することである程度コントロールすることができる。
具体的には一番大きな影響を与えている、テーブルのキャッシュを数を減らすことである

テーブルエントリのキャッシュ数を変更するには下記の項目を my.cnf に付け加える
数値は上限(osxでは1024)に達しないように調整する。

table_open_cache=400

すると一度オープンしたテーブルの file descriptor を保持しないようになるため、問題を解決できる。
なお、この対応方法はパフォーマンスに大きく影響をあたえる場合もあるので十分注意するべきである。
通常の linux ベースのサーバなどでは file descriptor の上限を上げるなどの対応を合わせて検討するべきである。