Windows10で起きたけど、多分これWindows7とかでも起きる気がする。 いつ頃からか忘れたが、Explorerでフォルダ作って名前入力してEnter押したとこで何十秒か固まる、という現象が多発していたのだ。リネームなどでも毎回固まるし。極端に重い、って感じの固まり方。 んで、Explorerに何か変なのが取り憑いたんかなー、とか思ってたんだけど、コマンドプロンプトからrenしても全く同じ固まり方なんで、FSの方がヤバかったりしないかな、とさすがに不安になって、似た症状の報告が無いか真面目に探してみた。 結論から言えば、多分Windows Searchのインデックスが巨大になると起きる、っぽい。言い換えれば、特定フォルダ以下にファイルが大量にあると起きる、と。 コントロールパネルの「インデックスのオプション」を開いたら、インデックスが百万個以上作られてたんで、問題が起きてるフォルダ
WordPressのローカル環境構築に便利なVCCWですが、唯一の欠点が動作が遅いことです。その欠点を克服する方法を知りました。それもお手軽かつ、効果が高いです。私はこれを導入することでかなり快適になりました。本番と大差ない状態です。それでは早速方法をお伝えします。 VCCWの導入については、WordPressローカル環境構築におすすめ！VCCW導入手順を参照ください。 VCCWを高速化する方法 VCCWのローカル環境を高速化する方法は、 Vagrantの共有フォルダのマウント形式をNFSに変更する だけです。たったこれだけでかなり高速化できます。Macの場合、標準でNFSに対応しているので、Vagrantファイルの編集だけで対応完了です。 WindowsにもNFSを利用する方法があります。後半に出てきます。 Vagrantの共有フォルダをNFSに変更する方法 Vagrantfileを編集
Vagrantが遅い！ ある日のこと。いつも通りvagrant upやらvagrant haltをしていたら、動作が非常に重くなりました。 最初のvagrant upは素早くささっと片づけてくれるのですが、そのあとのhaltやupが非常に遅い。 インストールしたソフトが重いのかとCPUのコア数を増やしたりメモリの割り当て量を増やしてみましたが何も解決しませんでした。 vagrant upするとマウントするところでこのようなエラーが出ます。VMの起動は出来ています。 Failed to mount folders in Linux guest. This is usually because the "vboxsf" file system is not available. Please verify that the guest additions are properly instal
最近AWSとかvagrantとかchefとか勉強していて、vagrantを使っていたのだけど、はじめからハマったのでメモ。 起こったこと vagrant upすることでVMが立ち上がるのだけど、以下の様なところまで言って全く起動しなくなった。 [default] VM already created. Booting if it's not already running... [default] Clearing any previously set forwarded ports... [default] Forwarding ports... [default] -- 22 => 2222 (adapter 1) [default] Creating shared folders metadata... [default] Clearing any previously set ne
先日別のチームから、 「PHPで作成したWebアプリの速度が遅いので助けてくれー」 という相談を受けた。 対応したものの、結構時間がかかって面倒だったので、 今後こういった問題が起こった時に使えるよう、チェックリストをまとめてやった。 基本的な内容だけど、 このチェックリストの内容をやってみて、それでもダメなら相談しなさい、 と伝えておくことで相談を減らすフィルタとして働いてくれるはずだ。 PHPプロジェクトに限らず、バックエンドでデータベースを使用している Webアプリのプロジェクトなら試す価値のあるものが多いはず。 調査や対応方法の手軽さ順で並べるとこんな感じ: Webブラウザのデベロッパーツールでレスポンスを計測する Webサーバ(Apache)のリクエスト時間をログに出力する ログ解析ツールでURL毎の付随リクエスト数を確認する データベースのスロークエリログを出力する プロファイ
Cで書くコードの方がCommon Lispで書くより速いって人がいたら、それは彼のCの技量が高すぎるってことだね。 “If you can't outperform C in CL, you're too good at C.” — Eric Naggum 最近、Common Lispの非同期Webサーバ「Wookie」を高速化する過程で、ボトルネックになっていたHTTPリクエストのパース部分を高速に処理するライブラリを書きました。 fast-http - A fast HTTP request/response parser for Common Lisp 既存のライブラリ「http-parse」よりも約10倍速く、Cのライブラリ「http-parser」より5%ほど高速です。 追記 (2014/10/26): 最適化をやり直し、現在は「http-parse」よりも約27倍速く、Cの「h
あるアプリケーションの作業にとって、スループットは最も重要なターゲットです。1つ例を挙げると、長時間実行されるバッチ処理のジョブです。ガベージコレクションが実行されている間、バッチジョブが時々1、2秒止まっても、ジョブ全体がすぐに完了すれば問題ありません。 人間が直接対話するアプリケーションから金融取引システムまで、実質的な他のすべての作業では、システムが1、2秒か、数ミリ秒以上反応しない場合、大変なことになり得ます。金融取引では、しばしば一貫した停止時間と引き換えに、スループットを犠牲にするだけの価値はあります。物理的に利用可能なメモリ量によって制限されるアプリケーションを持ったり、footprintを維持しなければならなかったりすることもあります。そのような場合、停止時間とスループットの面の両方で、パフォーマンスをあきらめなければなりません。 以下のトレードオフは度々起こります。 大部
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
発表資料: 全自動パラメータチューニングさん // Speaker Deck ソースコード: https://github.com/mirakui/tuningsan これは何なのか ハッカソンイベント「Open Hack Day Japan」にて、24時間の制限の中で開発し、90秒でプレゼンテーションした作品です 2013/2/16〜2/18 にかけてヤフー株式会社で開催された、「Open Hack Day Japan」という大規模ハッカッソンイベントで開発しました。 上記のプレゼンテーションは発表で使用したものです。 Open Hack Day Japan - Yahoo! JAPAN 本作品は、全参加作品の中で唯一のコマンドラインツールであり非常に地味でしたが、ありがたいことに KLab賞をいただくことができました。どうもありがとうございます。 指定した1パラメータの自動調整によって
Ben Corrie from VMware gave a talk on March 15, 2012 at the San Francisco Java Usergroup on tuning the JVM for a virtual machine. The event was filled to capacity, but fortunately you can find the video, slides, and a more detailed description of the talk below. The number of Java workloads running on virtualized infrastructure has been increasing exponentially over the last few years. Advancemen
J2EEがミッションクリティカルな分野に適用されるようになり、Javaのパフォーマンスチューニングの重要性はさらに高まっています。パフォーマンスチューニングにはさまざまなパラメータがありますが、中でもJava VMに関連するチューニングの効果は大きいといわれています。本稿は、Java VMに関連するチューニング手法を学ぶための前提知識を提供することを目的にしています（編集部）。 Java VMに関連するチューニングを行い、J2EEアプリケーションのパフォーマンスを上げるためには、Java VMについて詳しく知る必要があります。本稿は2回に渡ってJava VMの基本構造と動作原理を詳細に解説しますが、内容を理解するためにはプログラムがコンピュータ上で動作する基本原理とJava VMの基本用語を知っている必要があります。Java VMの基本用語に関しては、「実行スピードに挑戦するJavaアーキ
以下の５ステップで，適切なインデックスを作成し，SQLを高速化できる。 （１） パフォーマンスを改善すべきSQL（もしくはカラム）を特定 （１−１） ログを閲覧し，実行秒数の大きいものを抽出する。 （１−２） 統計テーブルを閲覧し，よく利用されるテーブルを特定する。 （２） 該当SQLのプランやコストを確認 （３） 該当カラムに対してインデックスを作成 （４） インデックスが作成されたことを確認 （５） SQLのプランやコストが改善されたことを確認 補足 ※↑ もくじジェネレータ で自動生成 DBはPostgreSQLを想定。 （１）パフォーマンスを改善すべきSQL（もしくはカラム）を特定 まず，インデックスを作成すべきカラムを見極める。 その方法は２つある。 （１−１）ログを閲覧し，実行秒数の大きいものを抽出する。 SQLの実行ログを閲覧する。 たとえば，Ruby on Railsなら，
C400がリリースされた今となっては、初の6Gbps対応SSDとして人気を誇ったC300の実勢価格も下降線。長らく20,000円の垣根を越えなかった128GBモデルも20,000円でお釣りが来る。C400の128GBモデルと比較し、5,000円の価格差は小さいとは言えないでしょう。鉄板Intel製SSDの牙城を崩し、小売りベースでシェア構図を塗り替えたのも記憶に新しい出来事です。 今回はP8P67 WSRevolutionのレビューでちょっと触れたドライバーによるトランスファーレイトの改善を深掘りし、現状のファームウェアにおけるC300 128GBモデルでのRAIDパフォーマンスを根こそぎ絞り出すべく、IRST (Intel Rapid Strage Technology)環境でのレビューをアップいたします。 写真1:Windows 7 Ultimate SP1 64bitの標準ドライバ
本連載も第6回を迎えましたが、第5回まではどちらかというとRedmineの業務機能面をメインに紹介してきました。今回からはシステム運用担当者向けに、Redmineを題材としてRuby on Railsアプリケーションをどうシステム運用・構築するかといった部分に観点を向け、役立つ情報をご紹介したいと思います。 とはいっても、システム運用という言葉は非常に広義で、本格的に行おうとすると様々な観点がありますが、今回は主にパフォーマンス（性能）向上に話を絞って進めたいと思います。 Redmineをより良いパフォーマンスで動かすためには Redmineを開発プロジェクト等で利用される方も多いかと思います。 特にRedmineは複数プロジェクトに対応したバグトラッキングツールですので、使い方によっては数多くのユーザからアクセスされるシステムとなります。 なので、個人用途で使う場合はそれほど気にしなくて
GC周りでトラブルシューティングした際の経験や、Web等で調べたことをまとめてみる。 前提 ・JVMは、Sun Javaを想定。(他は使ったことないです。。。) ・Sun Java 1.5-1.6を想定。 目標 マイナーGC、Full GCそれぞれが頻発することなく、かつそれぞれの実行時間を1秒未満に抑えること。 マイナーGCは1秒未満どころではなく、もっと短くなるべき。どれくらいが理想かは？(0.1秒未満ぐらいを目指したい？) 連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 理想的な状態は、上記に加えて、Full GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジェクト。逆にセッションオブジェクト等は長命オブジェクトとなる)を破棄させて、短命オブジェクトが、Tenu
hdparm でハードディスクを高速化する 2006.04.08 Linux もしハードディスクが PIOモードで動いていたらDMAモードに変更するだけで、14倍の速度アップ！ ■ハードディスクの読み出し速度を測定する まずは、HDDの読み出し速度を測る。 # hdparm -Tt /dev/hda /dev/hda: Timing cached reads: 1856 MB in 2.00 seconds = 929.07 MB/sec Timing buffered disk reads: 10 MB in 3.48 seconds = 2.87 MB/sec -Tスイッチは、キャッシュシステム、つまりメモリ、CPU、バッファキャッシュをテストするという意味。 -tスイッチは、キャッシュ上に無いデータを読み出して、ハードディスクのパフォーマンスをテストする。 読み出し速度が2.87MB
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: Excel VBA パフォーマンスレポート (Something U want): 坪崎誠司: 本
Amazon.co.jp: Linux-DB システム構築/運用入門 (DB Magazine SELECTION): 松信嘉範: 本
