ラベル パフォーマンス の投稿を表示しています。 すべての投稿を表示
ラベル パフォーマンス の投稿を表示しています。 すべての投稿を表示

2019年3月25日月曜日

ハイパースレッティングを無効化できない場合

■ハイパースレッティングとは
Intelの技術で1つのコアをOSに複数のコアとして認識させる機能です。
これによって本来のコア以上に多重処理をさせることができます。

■ハイパースレッティングを無効化する理由
アプリケーションによってはスレッドを分けると遅くなるものがあります。
1つの命令で計算量の多い処理を行っているアプリケーションがあたります。

■ハイパースレッティングの方法
通常はBIOSまたはUEFIからシステムやハードウェアのセットアップ項目にあるHyper-Threadingを無効にするだけです。

■ハイパースレッティングが無効にできない場合
私はHP hp zbook 17 g4 で経験したのですが、BIOSまたはUEFIの電源設定で「Deep Sleep」が有効になっている場合、項目を選択できず、無効化できなかったです。

この場合、以下の手順で行うとハイパースレッティングを無効にできます。
①「Deep Sleep」の無効化
②設定を保存して再起動
③ハイパースレッティングの無効化
④設定を保存して無効化

※②で設定を保存して再起動しない場合見かけ上無効化されますが、内部的に無効化できていない場合があるので行った方が良いです。(バグ?)

2015年5月6日水曜日

IBM、量子コンピュータの実用化に向けて

IBMが量子コンピュータの実用化に向けて取り組みを始めることを発表しました。

http://japan.zdnet.com/article/35063991/


現在、量子コンピュータを販売しているのはD-Waveのみです。 購入したのはgoogleとNASAのみです。
速度については発表されていないのでわかりませんが並列処理能力は発表されています。
 『スーパーコンピュータで10の10乗の並列ができるとしたとき、量子コンピューターでは10の154乗できる』

スーパーコンピュータと量子コンピュータでは得意な処理が違うため、一概に比較はできません。
概要としては、スーパーコンピュータは物理計算の処理に強いですが、量子コンピュータは並列処理、巨大なデータを扱いに強いです。

ビッグデータが昨今騒がれているなか、量子コンピュータはとても良いものになることは間違いないと思います。

また、IBMのWatsonとも相性が良いと思うので期待です。

量子コンピュータ実現に向けての課題は以下のようなものがあります。
・計算上で発生するエラーが多い。
・電力効率が悪い。
・単純に高コスト
・ハードウェアの大きさが大きいため既存のデータセンターで利用できない。
・効率的なアルゴリズムが開発されていない。
・現在広く使われているオープン系の技術知識、能力が役に立たない。

量子コンピュータにはさまざまな期待があるので今後の動向を抑えたいと思います。
また、これに対する日本企業の対応も調査したいと思います。

2015年3月25日水曜日

日立 量子コンピュータに匹敵するCMOSを発表

2015年2月23日にCMOS上で疑似的に量子コンピュータの計算手法を再現して量子コンピュータに匹敵するものを試作したことが発表されました。

http://pc.watch.impress.co.jp/docs/news/20150223_689576.html


近年、IT分野に力を入れている日立ですが、ついにここまでのものを作るとは本当に驚きです。
この技術を利用すればスーパーコンピュータの世界に革新をもたらすだけでなく、われわれが使うデバイスも大きな革新が起きることは間違いないです。

また、電力が最適化されているため、モバイルにもとても向いています。

そして、とてもありがたいのは、ノイマン型コンピュータというもっとも普及しているコンピュータの考え方のまま計算速度が爆発的に上がるのはありがたいです。

私は量子コンピュータに詳しくないのでわかりませんが、どのような計算処理に最適されるのでしょうかね?とても気になります。

2015年1月30日金曜日

【参加】ITpro Active製品選択支援セミナー アプリケーションパフォーマンス管理~攻めの運用でビジネスに貢献する~

アプリケーションのパフォーマンスというよりはパフォーマンス全般の監視、管理、改善に関する内容が入っていました。

パフォーマンスの難しさは昔から感じていましたが、改めて話を聞くと多くの知識が必要だと感じました。そのためにも関係者で協力して対応しないといけないと感じました。

昔、ある人が『がんばって性能を確保するより、ハードにお金をかければいいんだ』という話を聞きました。
その言葉は正しいですが、それは設計が正しいなどの前提があるのだと感じました。



以下、メモ。

ITpro Active製品選択支援セミナー
アプリケーションパフォーマンス管理~攻めの運用でビジネスに貢献する~

日程:2015年1月30日(金) 13:00~17:20
会場:ソラシティホールEAST](ソラシティカンファレンスセンター)
主催:ITpro Active


A-1 アプリケーションパフォーマンスを最大化するためのインフラ/運用管理とは
・2000年まではシステムをしっかりと作ることが求められ、~2005年に経営戦略との連携が求められるようになった。~2010年はビジネス的効果を求められる。近年は変革が求められる。
・経営者が求めるIT戦略のテーマ
 売上増大への直接的な貢献
 業務コスト削減
 顧客サービスの向上
・IT動向の重要指数はIT基盤の統合・再構築
 IT基盤が足を引っ張り、目的が実現できないことが問題になっている企業が多い。
・基盤への投資意欲は、スマートデバイス、ネットワーク(特に無線)、クラウドに集中している。
・基盤関連のコンサルティングを実施するとスマートデバイス、ネットワーク、クラウド、IT基盤が必ずテーマになる。
・今までは情報システム部門の目的を達成するためのIT基盤であったが、近年は業務部門の目的を達成するためのIT基盤になっている。
・UXの向上によってROIの改善効果があることがITRの調査で分かっている。(Webサイトの場合)
 社内システムでもUX向上によって生産性が倍以上の効果が出る。
 UXの向上でシステム利用率は3倍になる。
・UXは作ってみて使ってみないとわからないため、プロトタイプを作ってPDCAサイクルを回すしかない。
・UX中心設計/開発/運用の方法論、ITインフラ、評価・フィードバックが必要。


A-2 Splunkを示すEnterpise APM ~APM Big Data を提供するdynaTrace~
・近年はWEBサービスが広まり、ユーザーニーズが向上している。
 特にレスポンスに対する要求が強い。
・ログの種類が多くなりトラブル時やレスポンス悪化時にどれを見れば良いのかわからなくなっている。
 →ログ全体を可視化できるツールが必要。
・dynaTraceは各サーバにエージェントを導入し、該当サーバを利用した際にユニークIDを振ってログを出力し、次のサーバに渡す。
 その後、管理サーバに送り、レポート化する。
・dynaTraceであれば、すべてのユーザ、すべてのサーバの情報を取得しているため、一気通貫でログの関連付けができ、どこにボトルネックがあるわかりました。
・dynaTraceは他製品よりもサーバへの負荷が圧倒的に低い。
・dynaTraceの実績はグローバルで1000社程度、国内で40社。
・dynaTraceのライセンス体系はインストールしたエージェント数によって決まる。
・splunkはログの可視化のためのツールだが、実際はログ取得によって不正操作がないかセキュリティのために使うことも多い。
・splunkを利用し、ログデータから現在の発注された商品の現状を見せることができるようになった。
・サポートがよい企業を体験するとロイヤル顧客になる。
・見たいデータを瞬時に探すことができる。
・2月はどこのサイトでも最も売り上げが落ちるためキャンペーンを実施する。
 キャンペーンの効果が出ているかリアルタイムで把握し、必要に応じた対応をしたい。
・ログを可視化することでパフォーマンス劣化の予兆を事前に設置して顧客の満足度を向上できるようにしている。
・splunkは世界100か国で利用され、国内で1500社。
・splunkのライセンスはログ容量で決まる。


A-3 のためのアプリケーション可視化・最適化・高速化
~クラウドを含めたアプリケーション・ネットワークのパフォーマンス向上~
・製造業等は海外に拠点を持っていることが多く、WANの高速化の要求がある。
・WAN高速化製品はリバーベッドとCiscoの2強。
・安全性、柔軟性、信頼性、高いパフォーマンスがユーザのネットワークに対する要求。
・SteelHeadはWANの高速化、SteelCentralはネットワークの可視化ができる。
・SteelHeadはバイトキャッシュを採用している。重複排除している。
 さらに、拡張TCPを利用して高速化している。
・akamaiとriverbedで連携しインターネットのルートを最適化して、WAN高速化の限界を超えている。
・今後、クラウドの適応範囲を増やし、高速なクラウド利用環境を目指す。


A-4 Mobile App が主役の時代のAPM:CA Mobile App Analytics & CA APM9.7
・モバイルアプリケーションは利用しているアプリケーションが多い割に逆に使わなくなってしまうアプリケーションも多い。
・課題
 アプリケーションレビューの評価が低く、SNSなどでネガティブな情報が拡散されてしまう。
 アプリケーションの品質を保つことができない。利用環境が多様でありすべてをテストすることができないため、ユーザからの報告ないと気が付かない。
 ユーザに十分な体感を与えることができていない。
・CA MAAをアプリに入れてユーザがインストールするとユーザのスマートフォンから利用状況、クラッシュ情報をサーバに送る。
 WebはAPMで監視し、ネイティブとハイブリッドはMAAで監視する。
・収集したデータから、インストールの状況、アンインストール状況、利用状況(利用時間、利用回数)、クラッシュ情報のレポートが作成できる。
 クラッシュレポートはクラッシュの種類の分析もでき、アプリ開発のインプットとしてテスト改善につなげることができる。
・MAAは昨年にリリースされたばかりの新商品。CAが自社で開発した製品。

A-5 アプリケーション性能を管理するのに必要なこと
・性能という言葉は人によって使い方が違うため、要件を決めるときに言葉の整理が必要。
 また、必ず検証できるものだけで整理しないといけない。
・オンラインアプリはレスポンスタイム(処理時間と応答時間)とスループット
・バッチアプリは処理時間と処理可能データ量。
・性能を考えるうえでの原則
 ボトルネックを改善せよ
 何事も計測すべし
 仮説検証を繰り返せ
・性能チェックはどういうライフサイクルで使っていくかが重要。
 ツールだけでは要因特定は難しいため、ツールを使って要因を探す。
・性能を決定する要因
 外的要因(同時アクセス数)
 内的要因(データ量)
 ミドルウェア特性(処理内容、システムリソースの利用方法)
 アプリロジック(処理内容、システムリソースの利用方法)
 ミドルウェア特性とアプリロジックは作るときに考えること。痛い目にあいやすい。
 外的要因と内的要因は保守の中で発生する。予兆があるため見逃さないようにする。
・性能改善の技術は以下の4つしかない。
 圧縮、キャッシュ、分散、計算量の減少。
・分散はステートレスとステートフルの場合とある。
・システムのライフサイクル(要件定義から廃棄まで)の各工程で性能を意識する必要がある。特に運用設計の性能監視を忘れがち。
・性能は個人やチームの責任ではなく、プロジェクト全体の問題であるため、関係者で協力しあって目標達成に向けて対応することが必要。