on cloud waterproof レビュー
雨の日に走ると、足がびしょびしょになるのがいやで、前から気になっていたonのcloud waterproofを購入した。
www.on-running.com
onのランニングシューズは初めてで、waterproofのロード用にはcloudとcloudflyerがあるけど、art sportsの店員さんに伺ったところ、cloudがadidasのbostonぐらい(位置づけとして)、cloudflyerはそれよりもっとジョグ用、ということで、cloudにした。
サイズはいつもと同じサイズ。adidas japan boostとかと同じサイズ感。
で、とりあえず10km走ってみたけれど、
- 足が暑い
- 店員さんも、雨用でもあるけど、寒い日にすごくいい、と言っていた意味がわかった(夏に履いたらかなり蒸れそう)
- スピードがいまいち
- (これはcloud自体の性質)だいたい5分/1kmぐらいで走ったけれど、4分40秒ぐらいになると、けっこう頑張って踏み込まないと走れない
- 硬めではあるけど、ロードがダイレクトにくるわけではない
- ジョグにはよさそう
ということで、もともと雨の日用と思って買ったので、まぁジョグができればいいかな、と割り切って使う。
あと、走った日は小雨程度だったので、そもそも足が濡れるような状況ではなかったが、店員さんいわく、goretexほどの防水はないので、そこまでは期待しないでください、とのこと。
あとすごくスタイリッシュな感じなので、普段遣いによさそう。
atomosも取扱を始めたので、Hokaみたいに普段のスニーカーとして履く人も少し増えるかも。
pysparkをpython3で動かす時
pysparkをpython3で動かそうとすると、下記のエラーが出て困っていた。cloudera5.7.0。 RDDの集約系が動かない。
[SPARK-13330] PYTHONHASHSEED is not propgated to python worker - ASF JIRA
下記が原因。 https://github.com/apache/spark/blob/v1.6.0/python/pyspark/rdd.py#L73
で、PYTHONHASHSEED=0
を設定できればいいのだけれど、executorにも設定しないとだめで、どうしたらいいんだと思っていたら、confで設定できた。
export PYSPARK_PYTHON=~/py3spark/bin/python pyspark --conf "spark.executorEnv.PYTHONHASHSEED=0"
CentOS 7 で tmp fileを消してくれるserviceを停止する
RHEL7から採用されたsystemdですが、機能が豊富すぎてよくわかっていません。
とりあえずtmpファイルを消すsystemd-tmpfiles-clean.service
を止める方法を記載します。
忙しい方向け(すぐに止めたい)
とりあえず止めたい場合は、下記のコマンドを実行してください。
# 今動いているtimerを止める systemctl stop systemd-tmpfiles-clean.timer # 起動時にtimerが起動しないようにする systemctl mask systemd-tmpfiles-clean.timer
timerとか、maskとかいきなり出ていますが、興味がある方は下記へ
systemdのserviceとかtimerとか
よくわかっていません。とりあえず調べた範囲だけ書きます。
- service
- systemdで動かしたいコマンドの実態
.service
という拡張子(と言っていいのかな..)のファイル
- timer
.service
で作成したserviceを動かすタイマー- ここに起動する時間などを記載する
- つまりserviceで定義した内容をcron的に動かしたい場合に定義する
.timer
という拡張子(と言っていいのかな..のファイル- serviceと同じ名前で、
.timer
にすると自動で認識される
tmpfileを消すserviceの中身
service, timerをざっくりと説明しましたが、tpmfileを消すserviceの中身を見てみます。
- systemd-tmpfiles-clean.serviceの中身 (コメントは削除)
[vagrant@node1 ~]$ cat /usr/lib/systemd/system/systemd-tmpfiles-clean.service [Unit] Description=Cleanup of Temporary Directories Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8) DefaultDependencies=no Conflicts=shutdown.target After=systemd-readahead-collect.service systemd-readahead-replay.service local-fs.target time-sync.target Before=shutdown.target [Service] Type=oneshot ExecStart=/usr/bin/systemd-tmpfiles --clean IOSchedulingClass=idle
Unitとか、Serviceとかありますが、これはセクションと呼ばれるもので、[Service]セクションのExcecStart
に記載されている内容が、実行される内容です。
ここでは/usr/bin/systemd-tmpfiles --clean
ですね。
- systemd-tmpfiles-clean.timerの中身
[vagrant@node1 ~]$ cat /usr/lib/systemd/system/systemd-tmpfiles-clean.timer [Unit] Description=Daily Cleanup of Temporary Directories Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8) [Timer] OnBootSec=15min OnUnitActiveSec=1d
Timerセクションに記載されているところが、Timerの実態です。OnBootSec
は、起動後15分で、OnUnitActiveSec
は、serviceの起動間隔です。
サービスを止める
まずは上記のそれぞれが、どんなstatusなのかを見てみます。
[vagrant@node1 ~]$ systemctl status systemd-tmpfiles-clean.service ● systemd-tmpfiles-clean.service - Cleanup of Temporary Directories Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.service; static; vendor preset: disabled) Active: inactive (dead) Docs: man:tmpfiles.d(5) man:systemd-tmpfiles(8)
[vagrant@node1 ~]$ systemctl status systemd-tmpfiles-clean.timer ● systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static; vendor preset: disabled) Active: active (waiting) since 水 2016-08-24 03:54:23 BST; 7min ago Docs: man:tmpfiles.d(5) man:systemd-tmpfiles(8)
serviceのほうはinactive
になっていて、timerがactive
になっているので、このserviceはあくまでtimerによって起動されるものであることがわかります。
なので、timerをdisableにすれば止まる、と思いきや、systemd-tmpfiles-clean.timer
は起動時onをoffにできません。
いくつかのsystemdのコマンドを扱ったブログでは、とにかくdisable
で止めていますが、これで止まるものと止まらないものがあります。
disableで止まるもの・止まらないもの
それぞれのserviceのSTATE
を見ると、disableで起動時offができるかどうかがわかります。
[vagrant@node1 ~]$ systemctl list-unit-files -t service postfix.service UNIT FILE STATE postfix.service enabled
これはdisableできます。では、systemd-tmpfiles-cleanは..?
(timerはserviceに依存するので、本当はserviceだけ見ればよいですが、一応)
[vagrant@node1 ~]$ systemctl list-unit-files -t service systemd-tmpfiles-clean.service UNIT FILE STATE systemd-tmpfiles-clean.service static 1 unit files listed. [vagrant@node1 ~]$ systemctl list-unit-files -t timer systemd-tmpfiles-clean.timer UNIT FILE STATE systemd-tmpfiles-clean.timer static
static
になっていますね。で、このstatic
とはman systemctl
で見てみると、Table 1. is-enabled output
に (systemctl is-enabled ユニット名
でも、上記のSTATE
は見れます)
Unit file is not enabled, and has no provisions for enabling in the "[Install]" section.
と記載されています。つまり、static
の場合は、enableとかの管轄外なんですね。
で、もう一度systemd-tmpfiles-clean.serviceを見てみると、あれ?[Install] sectionがありません。
[vagrant@node1 ~]$ cat /usr/lib/systemd/system/systemd-tmpfiles-clean.service [Unit] Description=Cleanup of Temporary Directories Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8) DefaultDependencies=no Conflicts=shutdown.target After=systemd-readahead-collect.service systemd-readahead-replay.service local-fs.target time-sync.target Before=shutdown.target [Service] Type=oneshot ExecStart=/usr/bin/systemd-tmpfiles --clean IOSchedulingClass=idle
ではどこに?
After
とあるので、このユニットはいくつかのユニットに依存しています。
で、systemd-readahead-collect.service
を見てみると
[vagrant@node1 ~]$ cat /usr/lib/systemd/system/systemd-readahead-collect.service [Unit] Description=Collect Read-Ahead Data Documentation=man:systemd-readahead-replay.service(8) DefaultDependencies=no Wants=systemd-readahead-done.timer Conflicts=shutdown.target Before=sysinit.target shutdown.target ConditionPathExists=!/run/systemd/readahead/cancel ConditionPathExists=!/run/systemd/readahead/done ConditionVirtualization=no [Service] Type=notify ExecStart=/usr/lib/systemd/systemd-readahead collect RemainAfterExit=yes StandardOutput=null OOMScoreAdjust=1000 [Install] WantedBy=default.target Also=systemd-readahead-drop.service
[Install]セクションがありますね。 ということで、
systemd-readahead-collect.service
は[Install]セクションで記載されたtargetのタイミングでのみ起動する- これに依存している
systemd-tmpfiles-clean.service
もstatic扱いになる - それのtimerもstaticになるので、disable(enableも)の管轄外
- maskでoffにする
ということになります。
CDH5でのyarnのリソース設定のパラメータ
今更yarnで?ですが、今導入しようしていて、そのメモ。
基本的にはTuning YARNの項目だけなんだけど、yarnになってから細かく設定出来るかわりに複雑だねー、というところ。 URLにシートがあって、そこにスペックとかを入れると、関係するパラメータの数字を出してくれる。 出してくれるがしかし、入れようにも項目の中身がわからない。ということで、書きだした。
NMとして作用するパラメータ
yarn.nodemanager.resource.cpu-vcores
- Number of CPU cores that can be allocated for containers.
- NM単体で利用可能なvcoreの値
- clouderaのシートでは、(OS用などを差し引いたcore数 * Physical Cores to Vcores Multiplier) になっている
yarn.nodemanager.resource.memory-mb
- Amount of physical memory, in MB, that can be allocated for containers.
- NM単体で利用可能なmemoryの値
- clouderaのシートでは、物理メモリからOS用などを差し引いた値になっている
containerで有効なパラメータ
yarn.scheduler.minimum-allocation-vcores
- The minimum allocation for every container request at the RM, in terms of virtual CPU cores. Requests lower than this won't take effect, and the specified value will get allocated the minimum.
- コンテナがRMに要求するvcoreの最小値
yarn.scheduler.maximum-allocation-vcores
- The maximum allocation for every container request at the RM, in terms of virtual CPU cores. Requests higher than this won't take effect, and will get capped to this value.
- コンテナがRMに要求できるvcoreの最大値。この値でキャップがかけられる。
yarn.scheduler.increment-allocation-vcores
- Vcore allocations must be a multiple of this value
- この単位でvcoresの要求がインクリメントされる
- cloudera only
yarn.scheduler.minimum-allocation-mb
- The minimum allocation for every container request at the RM, in MBs. Memory requests lower than this won't take effect, and the specified value will get allocated at minimum.
- コンテナのメモリ最小値
yarn.scheduler.maximum-allocation-mb
- The maximum allocation for every container request at the RM, in MBs. Memory requests higher than this won't take effect, and will get capped to this value.
- コンテナがRMに要求できる最大のメモリ。この値でキャップがかかる。
yarn.scheduler.increment-allocation-mb
- Memory allocations must be a multiple of this value
- この単位でmemoryの要求がインクリメントされる
- cloudera only
MapReduce
mapred-default.xmlに記載される。
yarn.app.mapreduce.am.resource.cpu-vcores
- The number of virtual CPU cores the MR AppMaster needs.
- MRのAppMasterに設定されるvcores
mapreduce.map.cpu.vcores
- 1つのmapタスクで利用するvcoreの値
- これはそのままなので、わかる
mapreduce.reduce.cpu.vcores
- 1つのreduceタスクで利用するvcoreの値
- これもそのままなので、わかる
yarn.app.mapreduce.am.resource.mb
- The amount of memory the MR AppMaster needs.
- MRのAppMasterが使用するメモリ
mapreduce.map.memory.mb, mapreduce.reduce.memory.mb
- map, reduceでそれぞれ利用するメモリ
mapreduce.map.java.opts.max.heap, mapreduce.reduce.java.opts
- cloudera only
- map, reduceの際のjavaのheap size
- mapとreduce自体に設定したmemoryとは別なの?
mapreduce.task.io.sort.mb
- The total amount of buffer memory to use while sorting files, in megabytes. By default, gives each merge stream 1MB, which should minimize seeks.
- sortフェーズで利用するメモリ
シートで不明なパラメータ
- Physical Cores to Vcores Multiplier
この係数を、OSで使う分などで差し引いたものにかけることになっているが、そもそもなんでそんな考えなのかがいまいちわからない。 シートの説明欄には
Set this ratio based on the expected number of concurrent threads per core. Use 1 for CPU intensive tasks up to 4 for standard I/O bound tasks.
とある。I/Oで使っちゃうんだから、下駄を履かせなさいよ、的な感じ。
これをもとにyarn.nodemanager.resource.cpu-vcoresが求められるのだが、Apache Hadoopのページには"Number of CPU cores that can be allocated for containers."とある。 HPのHDPには
For configuring YARN, update the default values of the following attributes with ones that reflect the cores and memory available on a worker node.
とあるので、実コア数を超えない気がするが。うーん。
モンティ・ホール問題をpythonでシュミレーション
click
というモジュールを使っていますpip
してください- 本質的なところとは関係ないのでargparseに置き換え or ベタに数字入れる、など適宜修正してください
- 3.5.1で動かしています
- モンティ・ホール問題 - Wikipedia
- モンティ・ホール問題とその解説 | 高校数学の美しい物語
$ python monty.py if you do not re-select your answer : 0.3373 if you do re-select your answer : 0.6627 # ドアの数を変更 $ python monty.py --doors_number 5 if you do not re-select your answer : 0.203 if you do re-select your answer : 0.797 # 実行回数を変更 $ python monty.py --doors_number 5 --count 100000 if you do not re-select your answer : 0.19961 if you do re-select your answer : 0.80039