気になるモノ
2020-08-09T14:28:54+09:00
reich
メモ
Excite Blog
google カレンダーに日の出・日の入り時刻を表示する
http://reich.exblog.jp/240516799/
2020-08-09T14:24:00+09:00
2020-08-09T14:28:54+09:00
2020-08-09T14:27:03+09:00
reich
IT
本当は緯度経度に加えて高度や山の考慮も必要。
ここでは緯度経度だけで求めるサイトの情報を掲載する。
公的なサイトではないと思われるため、いつサービスが中断するかわからないことを了解してください。
WebCal.fi Know more missed holidays.
https://www.webcal.fi/en/manual_subscription.php#popular
Sun のところで、まず Select a location をクリックして、所在地の緯度と経度を調べる。
次に Latitude, Longitude に調べた値を入力。
Show sunrise and sunset をチェックし、ほかのチェックをすべて外す。
表示する期間を選択する。ただし、Show xx week into the past. はバグっていて、one を指定していても過去2週分を表示してしまう。
そして Show URL ボタンを押すと、画面の上部にURLが生成されているので、URLをコピーして google カレンダーに追加する(やり方は簡単なので調べてね)。
過去・未来の数週間分の日の出・日の入りを表示してみると、文字が大量に表示されてうざいので今日の日の出・日の入りだけ表示させてみた。
生成されたURLを次のように変更してから google calender に登録する。
http://www.webcal.fi/cal.php?id=42&format=ics&locationname=xxx-city.&lat=35.637188&lon=139.443503&ss=1&wp=-1&wf=1&du=km&color=%23FFD966&cntr=&lang=en&rid=wc
xxx-city の部分が都市の名前
lat と lon が表示する緯度経度
wp=-1&wf=1 がカレンダーに表示する前の週の数、後の週の数で、1日しか表示しないときは左の文字列にする。
good luck
]]>
nanaco ギフトコード登録のtips(ver.2)
http://reich.exblog.jp/239082490/
2019-01-28T21:10:00+09:00
2019-05-18T10:47:04+09:00
2019-01-28T21:10:05+09:00
reich
IT
ベネフィット・ワンの nanacoギフトコードは1万と思うけど。
というわけで少しでも楽をするこつ。
https://www.nanaco-net.jp/pc/emServlet?gid=XXXXXXXXXXXXXXXXXX
上記のxxxにギフトコードを入れて手続すると、4桁区切りを省力化できるテクを利用する。
1.relo倶楽部からのメールからコード発行のページにログインしてコード発行のページを表示する。
2.次の3つの列を含む表をコピーする。
コード1コード2有効期限
3. Excelにペーストする。4. コードの書かれた行の有効期限の右側の任意の列に次の式をペーストする。A3はそのシートのコード1の値のセルの座標に変更する。
=IF(A3="","",HYPERLINK("https://www.nanaco-net.jp/pc/emServlet?gid=" & A3))
5. 上記のセルをコードの数だけ下の行にコピーする。
すると、クリックしてログインするとコードを手入力で4つに分割して入力する手間を減らすことができる。
1つのコードについて画面遷移が3,4回あるのでクリックするだけで疲れるが、それでもかなり楽になるであろう。
Excelの1シートに数万円分のコードをまとめてコピーして、一気に登録することもできる。
Good Luck !
]]>
午前3時すぎにPCがカフカ状態
http://reich.exblog.jp/23746839/
2017-03-26T04:50:00+09:00
2017-03-26T04:49:59+09:00
2017-03-26T04:49:59+09:00
reich
IT
Sysinternals の procmon.exe で確認すると CompatTelRunner.exe が疑わしい。
検索してみると、コントロールパネルのセキュリティとメンテナンスにある、カスタマーエクスペリエンス向上プログラムを無効にするとよいらしい。
→すでに無効になっている。
さらに検索するとタスクスケジューラの Microsoft - Windows - Application Experience - Microsoft Compatibility Appraiser が毎日午前3時から遅延2時間の範囲で%windir%\system32\compattelrunner.exeを起動するようになっていた。
コンパネで無効になっているつもりだがタスクでは有効だったので(原因不明)、タスクは無効に設定した。
もうWindows 10 はストレスフルだな。
]]>
「接続がリセットされました。」「ERR_CONNECTION_RESET」の対策(netsh winsock版)
http://reich.exblog.jp/23661351/
2017-02-19T12:34:00+09:00
2017-02-19T12:34:38+09:00
2017-02-19T12:34:38+09:00
reich
IT
たとえば次のサイト。
https://zaif.jp/login
http://yonago.tax-furusato.jp/kifu_form.php
Windows 10 のPCだけ問題が起きていて Android のスマホなどでは問題が起きない。
Firewall を外してもダメ、履歴やcookie を消してもダメ。
Wifi 接続していたので、AP を削除して、APに再接続してもダメ。
結局、管理者として開いたコマンドプロンプトで次を実行して解決した。
netsh winsock reset catalog
調べた範囲の国内サイトの情報は全部はずれ。結局英語で調べて上記に行き着いた。
"According to a few Tom's Hardware members, this solution is useful and help them to fix the error."だそうです。
さすが Tom's Hardware はレベルが高い。
]]>
google chrome が遅くなった時のおまじない
http://reich.exblog.jp/22876420/
2016-06-05T09:08:32+09:00
2016-06-05T09:08:22+09:00
2016-06-05T09:08:22+09:00
reich
IT
OSのDNSキャッシュをクリア
ipconfig /flushdns
chrome のDNSキャッシュをクリア
chrome://net-internals/#dns
]]>
主人すらいない奴隷
http://reich.exblog.jp/22760582/
2016-04-29T09:28:00+09:00
2016-04-29T13:53:10+09:00
2016-04-29T09:26:10+09:00
reich
身辺雑記
いずれも日本の企業風土そのものに問題があるのでないかと思わされる事件である。
東芝の不正会計問題については例えば『東芝 不正会計の衝撃 ~問われる日本の企業風土~ - NHK クローズアップ現代+』に事情が紹介されている。
企業トップが利益の計上を指示し、『経理なんて言われたとおりに数字をつけておけばいいんだ』と発言し、幹部たちはそれに従うようになっていった。そして、『ついには本来会計をチェックすべき部門が、社長の意をくんで現場に圧力をかけるようになっていった』。
おそらく同じようなことが燃費不正の三菱自動車の社内でも起きていたと思われる。読売新聞は『相川社長らは記者会見し、新車開発の際に燃費目標を5度引き上げ、プレッシャーに感じた開発担当者が不正行為に及んだとの見方を示した』(燃費目標5度引き上げ「開発担当者が不正行為」 : 経済 : 読売新聞(YOMIURI ONLINE))と報じている。
「決算までの3日間で120億円の利益を出すよう迫る」といった無謀なトップの指示は旧日本陸軍がロジスティクスを無視して精神論で戦略を進めた悪夢に重なる。太平洋戦争の例を持ち出すと、陸軍幹部、大本営だけの問題ではく、日本国民も精神論をかざして戦争推進に加担していた側面があることを忘れてはならない。
こうも失敗が繰り返されると、日本人である我々が等しく共有する資質に由来している問題なのではないかと疑いたくなってくる。
なぜ我々日本人はコンプライアンス違反を告発することなく受け入れてしまい、そして最後にはむしろ積極的にコンプライアンス違反に加担してしまうのだろうか。
それは芥川賞作家の金原ひとみ氏が東日本大震災の福島原発事故後に発表したエッセイにおいて端的に指摘していることと同じであると思われる。東京新聞 2011年10月11日夕刊に掲載された『制御されている私たち 原発推進の内なる空気』から引用する。
『命より大切なものはないと言うが、失業を理由に自殺する人が多いとされるこの国で、失業を理由に逃げられない人、人事が恐こわくて何もできない人がいることは不思議ではない。
しかし多くの人が癌がんで死ぬ可能性よりも、個々の人間とは無関係、無慈悲に動いていくこの社会に対して、私たちが何もできないことの方が、余程絶望的かもしれないのだ。
私たちは原発を制御できないのではない。私たちが原発を含めた何かに、制御されているのだ。人事への恐怖から空気を読み、その空気を共にする仲間たちと作り上げた現実に囚われた人々には、もはや抵抗することはできないのだ。しかしそれができないのだとしたら、私たちは奴隷以外の何者でもない。それは主人すらいない奴隷である。』
金原氏の指摘は「空気を読む」、「場の空気」といった共同体に責任を預けて意思決定をしてしまう日本人の行動様式は奴隷そのものであると言い換えることができると思う。その理由は人事評価への恐怖に由来していると金原氏は喝破している。
なぜコンプライアンス違反を告発できないほど人事評価に恐怖するのか?いまだに日本社会は転職を良しとせず、大企業に長く勤めることを評価することにあると考えられる。会社にしがみついて定年まで勤めあげれば満額の退職金が得られるのに対して、中途で退職すれば退職金は減額される。また、中高年の転職は年収ダウンとほぼイコールと思われている。これでは空気を読んで、奴隷にならざるを得ない。
あるいはコンプライアンス違反を告発しないことは運命共同体としての会社を守る行為であると勘違いしてしまう面もあると思う。
一方、『【ワンポイントレッスン】新卒も中途も同じ?- 産経ニュース』によれば『欧米には集団としての新卒という概念がありません。新しく入ってきた社員という意味では“New employee"と言います』という。転職にペナルティがない社会がつくづく羨ましい。
転職にペナルティがなければ、退職金という概念がなければ、『主人すらいない奴隷』にならず、別の選択肢を選択することができるのではないか。逆に中途退社による退職金の減額の縛りが残り続ける限り、東芝の不正会計、三菱自動車の燃費偽装のような組織的な不正は繰り返されてしまうはずだ。
相次ぐ不正問題の根源は日本企業の人事制度の問題に由来しているのではないかと記したが、もしかすると日本社会に漂う閉塞感の根源もこの人事制度の問題に由来しているかもしれない。日本の労働者は退職金を身代金として企業に人質にされているといっては言い過ぎだろうか。
日本が変わるために、政治による変革を期待したい。
]]>
仕事がamazon化される日
http://reich.exblog.jp/22380437/
2016-02-06T18:08:00+09:00
2016-02-06T18:36:34+09:00
2016-02-06T18:08:43+09:00
reich
身辺雑記
例:ランサーズ, クラウドワークス
業務をクラウドを通じて委託することを意味するようだ。
会員数70万突破、業務委託総額728億円突破など、すでにきちんと商業ベースに乗っているようだ。
言葉の定義から当然ではあるものの業務案件ごとの募集が基本となっており、私が知っている業務の進め方から根本的な変革が起きていることに衝撃を受けた。
従来の業務委託は個人ではなく会社を選定もしくは打診をして、会社に業務委託するものと理解していた。突出したスキルを持つ個人に事実上業務委託する場合はあるものの、基本は会社対会社の契約であったはずである。ところがクラウドソーシングでは数万円レベルの案件であってもネット上の競りにかけて個人に発注することができるのである。
応募する個人は経歴やそれまでの応募案件、そしてクライアント側からの評価が可視化されている。これは発注側から見るとamazonの商品を選ぶのと同じと言える。
場合によってはクラウドソーシングで選抜したメンバーでチームを結成しプロジェクトを組むこともあるであろう。こうなるとプロフェッショナルなフリーランスがごく一般的になっていくはずだ。そのとき個人の評価を意味する星は名誉そのものになり、スターが現れるようになる。NHKで特集された元googleの及川氏のように。
一方で会社対会社の従来の枠組みにも時間をかけて相手の気性や得意分野を把握して業務を円滑に運用できるメリットはある。そのためクラウドソーシングもドライな競りだけではなく、既知の信頼できる個人に業務を委託し続ける習慣は続くであろう。
しかし業務をスレッド化してクラウドソーシングするプロジェクトの進め方は有能な個人を発見できる可能性が高まることから業務の効率化になるはずである。
スマホでアルバイトを募集する時代から、スマホでフルタイムの業務を募集する時代がやがて一般的になるかもしれない。トレンディドラマでこの題材がヒットすれば風向きはすぐに変わるだろう。
追記:
すでにクラウドワークスは上場していた(3900)。創業からわずか3年足らずの快挙。
株主にはサイバーエージェント、リクルートの子会社がリストアップされている。ちなみに3期連続赤字決算になる模様。]]>
chrome のキャッシュサイズ、キャッシュディレクトリを変更する起動スイッチ(追記あり)
http://reich.exblog.jp/15099343/
2015-11-03T09:30:00+09:00
2015-11-03T09:45:24+09:00
2012-04-21T12:27:01+09:00
reich
未分類
--disk-cache-dir
--disk-cache-size
私の環境では次のように設定した。キャッシュサイズはそれぞれ100MB.
chromeのアイコンを右クリックしてプロパティ、「リンク先」を私の環境では次のように変更する。
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disk-cache-dir="J:\chrome" --disk-cache-size=104857600
RAMディスクにキャッシュを移動すると、劇的にchromeの反応が早くなる。リンク先をクリックした途端にリンク先ページの描画が始まるような感覚になる。お勧めする。
RAMディスクはバッファローを推薦。
フレッツ光などのIPV6対応プロバイダーを使用していてIPV6の契約していない場合は上記のスイッチに加えて
--disable-ipv6
を設定するとよい。
また、プロキシーの設定が不要の場合はコントロールパネルのインターネット設定を起動し、接続タブを選択し、LANの設定ボタンを押して開かれる窓から、「設定を自動的に検出する」のチェックボックスを外すとよい。
chromeは複数のプロセスがすでに起動しているので、管理者権限で taskkill /f /im chrome.exe してすべてのchromeプロセスを停止するか、OSを再起動しないと、上記の設定は反映されない。
また、chrome の常駐を許可していると、RAMディスクの起動が間に合わなくて"disk-cache-dir"の設定が反映されない問題を経験した。対策としてはタスクトレイのchromeのアイコンをクリックして、バックグラウンドの動作を許可するのチェックを外すとよい。するとchromeは起動時に常駐しないので、RAMディスクの準備が終わった後にchromeがそれを使うようになる。
また、procmonを使って観察したところ
C:\Users\*\AppData\Local\Google\Chrome\User Data\Default\Local Storage\http_gendai.ismedia.jp_0.localstorage-journal
のようなパスへのアクセスが頻発していることに気付いた。
これはHTML5の機能らしい。これもuser-data-dirフラグにより移動することできる(c:\fooへ移動する例)。
chrome.exe --user-data-dir=c:\foo
ただし、google アカウントとの連携やクッキーなどもすべて初期状態になるので、上記のデフォルトパスからファイルをコピーしたのち、user-data-direは設定したほうがよいと思われる。
元ネタ
https://www.chromium.org/user-experience/user-data-directory
2015/8/30 更新=--media-cache-size は使用されていないスイッチのようなので削除。起動しないと設定が反映ないことを追記。
2015/09/20 chrome の常駐プロセスがあると、RAMディスクの準備が間に合わず、指定が無視される問題の対応法を追記。
2015/09/27 --disable-ipv6 を追記。プロキシーの自動検出を外す設定を追記。
2015/11/03 --user-data-dir を追記。]]>
コップ一杯の水没事故
http://reich.exblog.jp/21732585/
2015-10-12T18:40:00+09:00
2015-11-03T09:24:39+09:00
2015-10-12T18:40:48+09:00
reich
身辺雑記
以て他山の石としていただきたい。
ポピーが満開との新聞記事を読んだ日曜の朝、思い立ってその公園へ出かけることにした。
自宅から電車と歩きで1時間掛からないくらいだが、入園料がかかることもあり、機会がなく、入ったことが無かった。
昼食は秋晴れなのでレジャーシートを広げておにぎりを食べようと考えた。野外でおにぎりを頬張るのは2,3年前の高尾山登山以来のはず。リュックサックにコンパクトデジカメとミラーレスとマイボトルを入れて逸る思いで家を出た。
電車に乗って吊革にぶら下がっていると、自分の足元に水滴が落ちていることに気が付いた。マイボトルからお茶が漏れていたのだった。失敗したな、と思いつつ、ボトルをしめなおして元に戻したのだが、まるでお漏らしをしているような感じになってしまい、人がいないドアのほうに移動してやり過ごした。
公園に到着すると、入場券を買い求める人ごみがあることにびっくりして、その光景をまず撮ろうとリックサックを開いて、異変に気付いた。コンパクトデジカメに水滴がついていて電源が入らないのだ。バッテリーカバーを開くと、SDカードにまで水滴がついていた。まさかまさかミラーレスも故障していないよね、と電源を入れても反応がない。OMG!
…結局、花の写真はスマホで撮る羽目になった。
リュックサックの中にコップ1杯ほどのお茶がマイボトルから漏れて、2台のデジカメが水没してしまったのであった。ミラーレスの電池は過電流が流れてしまったのか、少し電池が膨らんで取り出そうとしてしてもなかなか取り出せなかった。
2つのデジカメの損失はおよそ5万円ほど。ミラーレスは型落ちの格安品を買ったので被害額は普通に比べれば少なく済んだが、まだ2年程度しか使っていないので元は取れたとは思っていない。
淡い期待を持ちつつ、一週間ほど乾燥させたが、やはり電源は入らなかった。
みなさん、カメラは水筒と同じバックに入れないこと、安物の水筒は買わないことをお勧めします。
くれぐれも気を付けて下さい。]]>
フレッツ光、使っている奴、ちょっと来い!
http://reich.exblog.jp/21458924/
2015-07-18T10:26:00+09:00
2015-07-18T10:31:29+09:00
2015-07-18T10:26:03+09:00
reich
IT
私はルータにPR-500KIを使っている。その場合次のように変更する。
トップページ > 詳細設定 > DNS設定
AAAA送信抑制エラー応答機能 はチェック
IPv6 IPoE通信優先機能 は優先しないを選択
すると今までの接続速度(転送速度ではなく、最初にページが表示されるまでの時間)がアホみたいに早くなるのです。Yhaoo なんかリンクをクリックした瞬間、次のページが表示する感じなのです。
これが光の実力だったのかと、いままで知らなかったことを後悔すること間違いなしです。
Chrome を 32bit 版から 64bit 版にしたときも速度改善に驚いたが、上記の変更はその3,4倍の驚きと感動を覚えてしまったほどである。絶対にいますぐ、設定を変えたほうがいい。いちおうIT関連のニュースはフォローしているはずの私が知らなかったのだから、フレッツ光ユーザの9割以上の人は知らないのではないだろうか(自惚れ入っています)。
以下、本件の解説。
Flet's 光には IPv6 フォールバック問題がある。
詳しくはググってもらうとして、簡単に説明すると、Flet's 光はNTTの回線内に従来のIPv4に加えてIPv6も対応している。ひかり電話や光TVなどはIPv6上でサービスが提供されているという。
あなたの使っているPCやスマートフォンやタブレットがIPv6 に対応していて(最近の機器は大抵対応している)、あなたがIPv6 の契約をプロバイダーとしていない場合(大半の場合)、次のような問題が発生する。
アクセスするサイトが IPv6 に対応している場合、URLの問い合わせを受けたDNSは IPv6 と IPv4 のIPアドレスを返答する。するとあなたの端末は規格に従ってIPv6のIPアドレスを先に使って接続しようとする。しかし、IPv6の契約をしていないのでNTTの回線(網)の外には出ることができず、タイムアウトの接続エラーになってしまう。するとあなたの端末は次にIPv4のアドレスを使ってアクセスするので、今度はサーバにアクセスできる。
タイムアウトする分、時間が余計にかかってしまう問題になってしまうわけであり、上記の通りIPv6からIPv4へ逆戻りする動作なので fall back 問題というわけです。
Windows ならIPv6を無効にする手段はあるものの、Wifi 接続している Android や iOS 機器はそれでは救うことが(簡単には)できない。ルータの設定変更がもっとも容易な対策と思われます。
以上です。
]]>
三浦朱門先生の筆力
http://reich.exblog.jp/21013239/
2015-03-17T23:07:00+09:00
2015-03-18T06:38:39+09:00
2015-03-17T23:08:11+09:00
reich
身辺雑記
初老の私がまず見ることのない雑誌だが、dマガジンのおかげで出会うことができた。
御年89歳、大正生まれの三浦朱門先生の筆力に魂消たのでご紹介したい。
『若者の性欲はほとんど盲目である。またその対象になった女性も、自分のキリョウに劣等感があれば、天女のように崇められて、体を求められると、アタシも一応は美女の部類なのかな、と自己満足が得られもしよう。それで結果的には彼の欲望に応ずることによって、容姿の劣等感を忘れられるし、男の側も自分も結構モテルんだ、と自惚れることができる。とにかく恋人ができるということは、劣等感を忘れて、ドラマの主人公のようなステキな男女になれることだ。だから若者にとって、恋愛とか恋人とかいうものは、劣等感を忘れられる、ほとんど唯一の機会なのだ。若者が恋愛に憧れる所以であろう。』
どうでしょうか。ほとんど90歳になろうというご老人とは信じられないほど生々しく闊達な精神が発露していると思われます。
なんとも明け透けな表現に、正直ビビッてしまったのであります。老境に入って男女関係を達観されて得られた筆致なのでありましょうか、もともとこのような見方をされる方なのでありましょうか。恐るべき老人もしくは偉人です。
]]>
釣りの出る金券はお得か?
http://reich.exblog.jp/21002819/
2015-03-15T11:58:00+09:00
2015-04-11T10:00:26+09:00
2015-03-15T11:58:43+09:00
reich
身辺雑記
分かったつもりだが、間違っているかもしれない。
命題=釣りの出る金券で買い物をするとお得なのか?
例:
9,800円で買った10,000円の商品券で100円の買い物をしてお釣りをもらうと9,900円の 現金が手に入る。
オトクになった金額と割引率は?
なんとなく釣りを貰ったので買い物をしたことによって100円儲けたように思える。
これは金券購入時の利益が現金化されただけであり、買い物をしたことによって利益が発生したわけではない。
金券購入時のお得になった金額は200円、割引率は 200/9800=約2.0%。
商品購入時にお得になった金額の計算:
商品は100円、支払いに要した金額は 9,800 -9,900=-100円。
オトクになった金額は 商品の金額から支払った金額を引くので 100 - (-100) = 200 円、割引率は00/9800=約2.0%。
つまり、商品の金額の多寡にかかわらず、全額を金券で支出した場合、釣りの出る金券の場合の割引率は金券購入時の割引率と同一になる。
結論=釣りの出る金券で買い物をするとお得になるわけではない。釣りの出る金券を買った時点のオトクが行使されるだけである。
釣りが出ない商品券+現金で購入する場合は、割引率の上限が金券購入時の割引率であり、足した現金の分、割引率が下がる。
おー定性的な説明しかできない。しかも十分な説明になっていない。
定式化がむつかしい。やっぱり自分はアホだった。
追記=小学生でもわかる証明があった。つり銭の出る金券は現金と等価。ゆえに割引率は購入時のそれであり、常に一定である。
なんだ1行で証明は済むのにどうして分からなかったのだろうか。地頭が悪い証明をしてしまった。
]]>
プロセスの優先度をコマンドラインで変更する
http://reich.exblog.jp/21002580/
2015-03-15T10:30:33+09:00
2015-03-15T10:30:19+09:00
2015-03-15T10:30:19+09:00
reich
IT
そこでプロセスの優先順位を下げてみた。
私は avira を使っているので次。
wmic process where name="avscan.exe" CALL setpriority "normal"
プライオリティは数値もしくは次の定数。
"idle", "low", "below normal", "normal", "above normal", "high priority", "realtime"
誤った設定がどのような結果になるのかわかる人だけ自己責任で使ってください。
]]>
DynCache(Microsoft Dynamic Cache Service) が動作しない
http://reich.exblog.jp/20942517/
2015-02-28T10:51:00+09:00
2015-04-11T10:11:13+09:00
2015-02-28T10:51:44+09:00
reich
IT
この調査の過程で分かった知見を記載することにより、後進の方々のお役に立ちたい。
【調査方法】
パフォーマンスメータのデータコレクタセットもしくは通常のグラフを用いて次のカウンタを計測する。
Memory - Available Bytes
Memory - System Cache Resident Bytes
Process - Page Fults/Sec
Process - Working Set - _Total
データコレクタセットを用いればバイナリログに保存でき、relog コマンドでCSVに変換できる。
ログを調べて、Working Set は肥大化していないのに時間とともにSystem Cache Resident Bytes が肥大化してAvailable Bytes が減少(その結果、Page Faults/Sec が多発する)していれば、システムファイルキャッシュメモリの肥大化がメモリ不足の原因であると判断できる。
そしてこのシステムファイルキャッシュの肥大化はOSの次の問題によって発生すると考えられる。
http://support.microsoft.com/kb/976618/ja
システム ファイルのキャッシュが物理メモリの大部分を使用するとアプリケーションおよびサービスのパフォーマンスの問題が発生します。
(以下、関連知識)
利用可能メモリはパフォーマンスメータの Memory - Available Bytes の値である。メモリ使用率を計算するときの分母には、BIOSやビデオメモリが使用する領域があるので、実装メモリのサイズではなく、OSが認識している物理メモリのサイズを使う必要がある。
【対策】
マイクロソフトのナレッジベースに対策として紹介されている、Microsoft Dynamic Cache Service(DynCache)には大きな罠があり、数日ハマってしまったので注意を喚起したい。
※DynCacheサービスのドキュメントは説明が不足しているため、非常にわかりにくい。ソースコードを見たほうが早いかもしれない。
Dyncacheには動的管理と静的管理の2つの方法があり、MaxSystemCacheMBytesの値が1-99のときは動的管理になり、キャッシュの最大制限値を利用可能メモリの何%に、201以上の場合は静的管理になり、キャッシュの最大制限値は指定した値(MB)になる。
動的管理は指定したプロセスが動作したときだけ、各プロセスごとに指定したメモリのサイズだけOSが利用できるメモリから減算する(指定したプロセスのメモリのために余裕を持たせる)ことによって実現する。そして減算済みのメモリサイズの指定した%分をファイルシステムキャッシュの上限に設定する。つまり指定したプロセスが動作していなければ、その分のメモリをキャッシュに割り当てることになる。というのはなるべくメモリをシステムファイルキャッシュに割り当てたほうがよいという考えに基づいているのであろう。プロセスを何も指定しなければ単にOSが利用できるメモリの何%をファイルシステムキャッシュの上限に指定することになり、事実上、静的管理と同じになる
私が罠にハマったのは、使用したバイナリモジュールの問題であった。
DynCache.zip には Retail フォルダに
AMD64
I386
IA64
フォルダがある。
問題が起きたサーバはAMDではなく、インテルの64itプロセッサを載せているので i386 を使用するのだろうと考えた。IA64 は遠い昔、HP とインテルが共同開発した、Itanium プロセッサのアーキテクチャであり、サービスとして登録しようとするとエラーが起きてしまう。ところが I386 のバイナリはインストールできるものの正しく動作しない。同じく Debug フォルダの I386 のバイナリも正しく動作しない。(Debug 版はDebug View を使うとデバッグメッセージを出力するはずが出力されない)。
手元の Windows 7マシンでは同じI386のバイナリが正しく動作するのでさらに混乱してしまった。
結論としては AMD64 フォルダのバイナリを使うのが正解であった。Intel のx86版の64bit命令アーキテクチャは AMD 仕様を採用した経緯があるので、インテルの x86 系の 64bit CPU を搭載している場合、AMD64 フォルダの exe を使う必要があった。私が使用した Windows 7 は 32bit 版だったので I386 フォルダのバイナリで正しく動作していたのであった。ドキュメントに一言あれば迷わずに済んだものをと嘆息せざるを得ない。私と同様に誤ったexeを使って問題が解決せず、苦しんでいる人もいるはずである。
Debug 版のメッセージを観測するときに使用できる Debug View はこちら。
https://technet.microsoft.com/ja-jp/sysinternals/bb896647.aspx
【検証方法その1・システムファイルキャッシュ肥大化の再現方法】
数GBのファイルを読み書きするとSystem Cache Resident Bytes が数GB程度まで急上昇する。1分ほどその状況が続き、また元の少ない状態に戻ってしまう。
DynCache サービスを静的管理の方法で設定した後、肥大化の操作を行うとSystem Cache Resident Bytesは設定した値を上限にピタリと止まる。これが肥大化を防止できた証である。
【検証方法その2・キャッシュ最大制限値の確認】
マイクロソフトのナレッジベースに記載されているとおり、DynCacheはGetSystemFileCacheSize API 関数とSetSystemFileCacheSize API 関数をコールするものである。
一度設定した最大制限値は次回リブートまで保持される(リブートで消えてしまうので自動起動のサービスで再度設定する必要がある)。
従ってOS起動後GetSystemFileCacheSize を実行すれば、DynCacheが正しく動作したかどうか確認できることになる。GetSystemFileCacheSize API をコールして結果を表示するPower Shell スクリプトが次の掲示板に掲載されている。
http://stackoverflow.com/questions/5898843/c-sharp-get-system-file-cache-size/17875550#17875550
上記のスクリプトを GetSystemFileCacheSize.ps1 に保存したら、
コマンドプロンプトでps1ファイルを保存したディレクトリに移動したのち、
PowerShell と入力、
Set-ExecutionPolicy RemoteSigned を入力(セキュリティポリシーを変更)、
.\GetSystemFileCacheSize.ps1 を入力して実行すればよい。
出力されるフラグの意味は次を参照のこと(ビットごとのOR演算になる)。
https://msdn.microsoft.com/en-us/library/windows/desktop/aa965224%28v=vs.85%29.aspx
以上、健闘を祈る。]]>
WPA: Invalid EAPOL-Key MIC when using TPTK - ignoring TPTK
http://reich.exblog.jp/20890244/
2015-02-15T08:28:00+09:00
2015-02-28T08:52:35+09:00
2015-02-15T08:28:58+09:00
reich
Raspberry Pi
家のWifi に接続しようとしたら
WPA: Invalid EAPOL-Key MIC when using TPTK - ignoring TPTK
が出力された後、切断・接続を繰り返してうまく動作しなかった。
原因切り分けはできていないのだが、次に示すconfファイルの変更、
もしくはRaspberry Pi を再起動したら切断は起きなくなった。
もしかすると wpa_supplicant がすでに常駐していたのかもしれない。
その場合、ps -e|grep wpa でプロセス番号を見つけて kill すればよいと思う。
/etc/wpa_supplicant/wpa_supplicant.conf の内容は次の設定だけで動作することが分かった。
network={
ssid="xxx"
psk=xxx
}
wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf
にて起動させてみると、メッセージに CCMP の文字が表示されている。
wikipedia を参照していただくとわかるが、これはAESを使ったプロトコルなので、AESを使った暗号化が
適用されていると思われる。
状態を確認するには
wpa_cli status
を実行する。
すると上記のwpa_supplicant.confを使用した状態で次のように CCMP で暗号化されていることが確認できた。
Selected interface 'wlan0'
bssid=xxx
ssid=xxx
id=0
mode=station
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
ip_address=192.168.1.100
address=xxx
掲題のトラブルを調べている間に次の CISCO のサイトを見つけた。
http://www.cisco.com/cisco/web/support/JP/112/1122/1122209_wlc-debug-client-j.html
WPA2 はこれだけ複雑な状態遷移を経て実現されているのかと驚いた次第。
開発者の方々に感謝。]]>
https://www.excite.co.jp/
https://www.exblog.jp/
https://ssl2.excite.co.jp/