FirefoxでYoutubeを見続けるとどうなるか タスクマネージャを開いてFirefoxでYoutubeを見てみると、おかしいことがわかります。 動画を見ているだけなのにSSDへの書き込みが連続して発生するのです。 試しに後述のabout:configでbrowser.cache.disk.parent_directoryでキャッシュの位置をUSBメモリなどにしてみるとよくわかります。 またキャッシュされた内容はアドレスバーにabout:cacheと入力すると確認できます。 そしてわかったこと。 なんとFirefoxはYoutube動画をすべてディスクキャッシュとしてため込んでいるのです。 動画なんて何度も見ることは少ないのでキャッシュする意味は少ないはずです。 これではSSDの書き込みが延々と発生し、SSDの寿命に影響が出そうです。 Firefoxのキャッシュの仕組み アドレスバーに
どうも、ロボ太(kaityo256)です。趣味は他人のAdCを乗っ取ることです(乗っ取るとは言ってない)。これまでもスパコンポエムをいくつか書いてきましたが、せっかくスパコンポエムAdCがあるので一日お邪魔させてもらいます。 スパコンランキング スパコンにはTop500という有名なランキングがあります。HPLという、バカでかい連立一次方程式を解いて、その性能を競うものです。その名の通り、世界で上位500位までがランキングに入ります。6月と11月の年に二回開催され、ISCやSCという会議で発表されます。ずいぶん昔、「二位じゃダメなんでしょうか？」で有名になった事業仕分けにおいて、スパコンにおける一位とか二位というのは、狭義にはこのランキングでの順位を指しています。HPLがスパコンの性能評価として妥当かどうかについて、以前ポエムを書いたのでそっちを参照してください。 さて、このランキングの良い
AWS、独自開発したARMベースの「Graviton 2」プロセッサを、「Amazon ElastiCache」のデフォルトプロセッサに Amazon Web Services（AWS）は、同社がマネージドサービスとして提供するインメモリキャッシュサービスの「Amazon ElastiCache」において、プロセッサの選択肢のデフォルトが「Graviton 2」プロセッサになることを明らかにしました。 これは、AWSが10月8日付で公開した「Amazon ElastiCache が、M6g および R6g Graviton2 ベースのインスタンスをサポートするように」の発表の中で、「Graviton2 インスタンスは、ElastiCache のお客様のデフォルトの選択肢になりました。」とさりげなく発表されたもの。 この発表の中でAWSは、Graviton 2ベースのインスタンスを用いたAm
※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構食っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「
!告! ぶろぐのhttps化によってSyntax Highlighterが機能しなくなってしまいましたので 現在正常に閲覧できるよう過去の記事を適宜修正中です！！ ←前回 次回→ 今から4年以上前、STM32F7ではぢめてキャッシュという概念に対峙し、分かった つもりでお茶を濁してきましたがH7になった今どうしても正面から向き合わざるを 得ない事態になってしまいました…それも最悪な形で！！ ●Cortex-M7のキャッシュにエラッタ発覚! オイオイオイ死ぬわ私。(一般には今年春くらいに知れ渡った内容です) 要約しますとCortex-M7系マイコンでキャッシュポリシーをライトスル―にした状態で Double-WORD(ARMの場合8バイト)の読み書きを同一のアドレスで行った時に、読み 出しの時にデータが壊れる事があるという内容…しかも現行の全リビジ
All of Percona’s open source software products, in one place, to download as much or as little as you need.
この記事は、シェルスクリプトの記事よりも前に読んだような気がする。同じくらい古い記事だけれど、ちょっと書いてみる。記事への反論はいくつか検索すると見つかって、たぶんみんな知っていることなのだと思うけれど、まとまって書かれている文章はないみたい。 tl;dr read(2) と mmap(2) の性能差に絶対的な回答はない。どちらか一方が常に高速だと主張している文章は、根拠が証拠とともに明確に書かれていない限り信用しないほうが良い。 メモリコピーのコストが高かった時代と、L1キャッシュが巨大になってメモリコピーのコストが低くなった時代と、SMPが一般的になってメモリのマッピング処理のコストが高くなった時代とで、この性能差は頻繁に入れ替わっている。少なくともスループットとレイテンシを分けないで分析できるものではない。 まず当該記事には技術的な間違いがいくつかある。 「mmap()はユーザランド
latency.txt P3z �� ��q �� Latency Comparison Numbers (~2012) ---------------------------------- L1 cache reference 0.5 ns Branch mispredict 5 ns L2 cache reference 7 ns 14x L1 cache Mutex lock/unlock 25 ns Main memory reference 100 ns 20x L2 cache, 200x L1 cache Compress 1K bytes with Zippy 3,000 ns 3 us Send 1K bytes over 1 Gbps network 10,000 ns 10 us Read 4K randomly from SSD* 150,000 ns 150 us
STM32H7におけるキャッシュ一貫性を保ったDMA転送の方法として、MPUによる設定を解説します。 STM32H7ではF7と異なり、DMAコントローラからDTCM領域にアクセスできないため注意が必要です。 GitHubでソースコードを公開しています。(Memory-to-Peripheralの場合のみ 概要 Cortex-M7コアにはL1キャッシュが搭載されているため、DMA転送時にはデータ化け(キャッシュの一貫性が崩れる問題)に気を配る必要があります。 STM32F7では、DMA対象データをキャッシュの影響を受けない「DTCM領域」に置くことが、データ化け対策として有効でした[脚注1]。一方でSTM32H7では、STM32F7からアーキテクチャが変更され、DMAコントローラからDTCM領域(0x2000 0000～)にアクセスできなくなりました[脚注2]。無理にアクセスするとHardF
はじめに drop_cachesにwriteしてみて、その前後での/proc/meminfoやfree(1)コマンド結果を観察するような記事はたくさんあるけど、drop_cachesにwriteしたときに何をやっているのかを詳しく解説したような記事が全然見つからなかったので、自分で調べてみることにした。 ・・・という間違いを犯して泥沼にハマり貴重な休みを潰してしまったとあるエンジニアの活動を記録した記事である(たぶん) なお、Linux-4.12くらい、procps-ng-3.3.12くらいを見ています。 ページキャッシュの概要 概要 そもそも通常は、あえてdrop_cachesに値を書いて操作する必要が出るような場面はないと思われる。敷いていえば、ページキャッシュに乗ってる場合と乗っていない場合とでのベンチマークをしたいときくらい？ まれに/proc/meminfoのMemFreeが少な
LinuxでI/Oと格闘していると、重要なファイルがどのタイミングでキャッシュに乗ってくるかは死活問題になります。 このファイルってどれくらいキャッシュに乗っているの？という時に便利な vmtouch というツールがあったのでご紹介。 導入方法 導入はいたって簡単。 $ git clone https://github.com/hoytech/vmtouch.git $ cd vmtouch $ make $ sudo make install ちょっと調査で使いたいだけなら make install はやらなくてもOKです。インストールした場合は /usr/local/bin に実行ファイルがインストールされてmanも利用できるようになります。 基本的な使い方 まずは動作の確認に使うファイルを作成します。90000行です。 $ for n in `seq 10000 99999`;do
さくらインターネット Advent Calendar最終日は、硬派にLinuxのメモリに関する基礎知識についてみてみたいと思います。 最近はサーバーを意識せずプログラミングできるようになり、メモリの空き容量について意識することも少なくなりましたが、いざ低レイヤーに触れなければいけないシチュエーションになった際に、OSを目の前に呆然とする人が多いようです。 基本的にLinux のパフォーマンスについて、メモリをたくさんつめばいいとか、スワップさせないほうが良い とか、このあたりは良く知られたことだと思います。 ただ、なんとなく ps コマンドや free コマンド などの結果を見るだけでなく、もう少しメモリのことについて掘り下げてみてみたいと思います。 メモリとキャッシュ Linux におけるメモリの状態を大きく分けると「使用中のメモリ」「キャッシュ」「空きメモリ」「スワップ」の 4 つに分
Linuxのバッファキャッシュとページキャッシュの違いは？ 2012-10-25 Linuxが管理するキャッシュ領域には、バッファキャッシュとページキャッシュ領域があって、topコマンドや/proc/meminfoの「bufferes」「cached」という項目を見れば、現在のそれぞれのキャッシュ領域がどの程度なのかを確認することができる。 どちらも、ディスクの読み書きをキャッシュしてデータへのアクセスを高速化するという点では同じだが、それぞれがどのような意味で、どういう違いがあるのかについて、Quoraに分かりやすい解説があったので、翻訳してみた。 ページキャッシュは、ファイルI/Oを最適化するために、ファイルのページをキャッシュする。バッファキャッシュは、ブロックI/Oを最適化するために、ディスクブロックをキャッシュする。 Linuxカーネル2.4よりも前では、2つのキャッシュは明白に
Overview Ccache is a compiler cache. It speeds up recompilation by caching previous compilations and detecting when the same compilation is being done again. Ccache is free software, released under the GNU General Public License version 3 or later. See also the license page. Latest release: version 4.12.1 News All news Features Supports GCC, Clang, MSVC (Microsoft Visual C++) and other similar com
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く