タグ付けされた質問 「buffer」

このタグは、パイプバッファーを含むカーネルバッファーキャッシュに関する質問用です。これらは、最近アクセスされたファイルや頻繁にアクセスされるファイルを格納するために使用されます。

13
パイプのバッファリングをオフにします
2つのコマンドを呼び出すスクリプトがあります。 long_running_command | print_progress long_running_commandプリントは進歩が、私はそれに不満です。print_progressより良いものにするために使用しています(つまり、進行状況を1行で出力します)。 問題:stdoutにパイプを接続すると、4Kバッファーもアクティブになります。素敵な印刷プログラムには何も...何も...何も... たくさんありません... :) 4Kバッファーを無効にするにはどうすればよいですかlong_running_command(いいえ、ソースがありません)?
395 shell  pipe  buffer 

6
パイプバッファーの大きさは?
のコメントとして、makefileの「| true」がユーザーcjmが書いた「|| true」と同じ効果がある理由について混乱しています。 避けるべきもう一つの理由| trueは、コマンドがパイプバッファーをいっぱいにするのに十分な出力を生成した場合、trueを待ってブロックすることです。 パイプバッファーのサイズを調べる方法はありますか?
146 pipe  buffer 

12
vim-現在の貼り付けバッファを使用して「単語を変更」するにはどうすればよいですか
貼り付けバッファーにテキストがあります。たとえば、yw(yank word)を実行しましたが、バッファーに「foo」があります。 ここで「バー」という単語に移動し、それを貼り付けバッファーに置き換えたいと思います。 テキストを手動で置き換えるにはcw、新しい単語を入力します。 「単語の変更」を行うことができますが、置換単語を手動で入力する代わりに、貼り付けバッファの内容を使用できますか? 私が今持っている最良のオプションは、置換したい単語の先頭に移動してdw(単語を削除)、他の場所に移動してyw(ヤンク語)、置換領域に戻って実行することですp(貼り付け)これは、特に同じ画面上にない場合は少し不器用です。
86 vim  vi  replace  buffer 

3
同期すべき哲学に真実はありますか?同期; 同期; 同期しますか?
2000年にシスコシステムズで働いていたLinuxを初めて紹介したときsync、ファイルシステムの破損やデータの損失を防ぐためにバッファをディスクにフラッシュするコマンドのメリットを学びました。同僚からだけでなく、大学の友人からsync、「一度」ではなく、常に「数回」または「たくさん」、つまり5〜10回実行するように言われました。 それ以来ずっとこの習慣を続けていますが、これには何かメリットがありますか?これを聞いた人はいますか?そして、最も重要なことは、誰でもあなたがsyncそれが効果的であるために複数回実行する必要があるという考えに対して/に対して良い根拠/経験的証拠を提供できますか?

3
vimバッファーの名前を変更する方法
vimでバッファの名前を変更することは可能ですか? 具体的には、Conque Shellを使用してvimでシェルを開き(各シェルはバッファー内にあります)、複数のシェルを使用しています。 10: bash - 1 11: bash - 2 私のバッファリストに。これらのバッファの名前をより意味のある名前に変更したいと思います(たとえば、「bash-2」ではなく「mercurial」)。出来ますか?
26 vim  buffer 

5
Linuxのバッファキャッシュのサイズを制限する
Linuxカーネルにバッファキャッシュに特定の割合のメモリのみを使用するように指示する方法はありますか?私/proc/sys/vm/drop_cachesは一時的にキャッシュをクリアするために使用できることを知っていますが、例えばメインメモリの50%以上に成長するのを防ぐ永続的な設定はありますか? これを行う理由は、ディスクからのデータを常に提供し、数時間以内に物理メモリ全体をバッファキャッシュとして使い果たすCeph OSDを実行しているサーバーがあるためです。同時に、大量(数十GB)の物理メモリを割り当てるアプリケーションを実行する必要があります。一般的な信念に反して(バッファキャッシュに関するほぼすべての質問に与えられたアドバイスを参照)、クリーンキャッシュエントリを破棄してメモリを自動的に解放することは瞬時ではありません:バッファキャッシュがいっぱいになると、アプリケーションの起動に最大1分かかることがあります( *)キャッシュをクリアした後(を使用echo 3 > /proc/sys/vm/drop_caches)、同じアプリケーションがほぼ瞬時に起動します。 (*)この1分間の起動時間中、アプリケーションは新しいメモリに障害が発生しますが、Vtuneによると呼ばれる関数によると、その時間の100%がカーネルで費やされますpageblock_pfn_to_page。この機能は、巨大なページを見つけるために必要なメモリ圧縮に関連しているようで、実際に断片化が問題であると考えさせられます。

1
スクロールバックとスクロールバックバッファーとは正確には何ですか?
やなどのプログラムの「スクロールバック」や「スクロールバッファ」とは何ですか?bashまたscreen、tty、実行中のプログラム、stdin / stdout / stderrとはどのように関係していますか? これが私がこれまでに見つけた「scrollback」の唯一の定義です(archlinux wikiで): スクロールバックは、テキストコンソールに実装されている機能であり、ユーザーが戻って画面からスクロールしたテキストの行を表示できるようにします。これは、ビデオアダプタとディスプレイデバイスの間にこの目的のために作成されたバッファによって可能になります。スクロールバックバッファ。 しかし、これは私にとってより多くの質問を提起します: 「サブルーチン」や「機能」などの「機能」を意味しますか? このスクロールバックバッファ用のUnix標準またはAPIはありますか? 以下のようなプログラムの「スタック」でvimに発売screenに発売bashに発売されssh、これらのプログラムのスクロールバックバッファを制御している端末エミュレータ、に発売? また、スクロールバックをファイルscreenにダンプするのに使用しました。このファイルの上部には多くの空白があり、ターミナルエミュレータが表示する「ビュー」は、バッファの最後の数行にすぎないようです。 これはvim、親シェルのスクロールバックバッファに一時的にアクセスするため、プログラムがターミナルウィンドウ全体を「クリア」できるのはなぜですか? またはvim、親スクロールバックバッファーの上に何らかの方法でオーバーレイされる独自のスクロールバックバッファーを使用しますか?

2
パイプ、データはパイプラインでどのように流れますか?
パイプラインでデータがどのように流れるのか理解していないので、誰かがそこで何が起こっているのかを明確にしたいと思っています。 コマンドのパイプラインは、ファイル(テキスト、文字列の配列)を1行ずつ処理します。(各コマンド自体が行ごとに機能する場合。)テキストの各行がパイプラインを通過する場合、コマンドは前の入力が入力全体の処理を完了するまで待機しません。 しかし、そうではないようです。 これがテスト例です。テキストのいくつかの行があります。それらを大文字にして、各行を2回繰り返します。私はそうしcat text | tr '[:lower:]' '[:upper:]' | sed 'p'ます。 プロセスを追跡するために、「インタラクティブ」に実行できますcat。入力ファイル名をスキップします。パイプラインの各部分は、行ごとに実行されます。 $ cat | tr '[:lower:]' '[:upper:]' alkjsd ALKJSD sdkj SDKJ $ cat | sed 'p' line1 line1 line1 line 2 line 2 line 2 しかし、完全なパイプラインは、入力が完了するのを待ってからEOF結果を出力するだけです。 $ cat | tr '[:lower:]' '[:upper:]' | sed 'p' I am writing... …

3
不要なバッファが開かないようにする
私は毎日のJavaScript編集にemacsを使用し、Cx LEFTとCx RIGHTを使用するバッファーを切り替えていますが、これで問題ありません(変更しているファイルのパスを知ることが難しい場合でも)。 私の問題: 起動時に私は常に持っている*scratch*と*Messages*開かれ、私は入れていると考え(kill-buffer "*scratch*")、私の.emacsにしても問題が解決するだろうが、そうではありません、あなたが提案を持っているのですか? ファイルを開くときは常にTABオートコンプリートを行うので、補完*Messages*のオプションを含む新しいバッファーを作成するたびに、これを作成しないようにするにはどうすればよいですか、または、より良い方法として、emacsにそれを強制終了させます私の選択をしましたか? 私が一番上で言ったように私がナビゲートして「あるべき姿」ではない何かをしていると思うなら、あなたの意見を言ってください。
18 emacs  buffer 


1
カーネルスペースでパケットをキャプチャするためのバッファサイズ
のmanページをtcpdump見ると、バッファがいっぱいになるとカーネルがパケットをドロップする可能性があります。私は疑問に思っていた: そのサイズは構成可能および/または ディストリビューションのサイズはどこで確認できますか? manページから(簡単に参照できるように): パケットが「カーネルによってドロップ」(これは、OSがアプリケーションにその情報を報告する場合、tcpdumpが実行されているOSのパケットキャプチャメカニズムによって、バッファスペースの不足によりドロップされたパケットの数です。そうでない場合は、0として報告されます。

3
ページキャッシュに100%ページインされたファイルが別のプロセスによって変更されるとどうなりますか
ページキャッシュページが変更されると、ダーティとマークされ、ライトバックが必要になることがわかりますが、次の場合はどうなりますか。 シナリオ: 実行可能ファイルであるファイル/ apps / EXEは、ページキャッシュに完全にページインされ(そのページはすべてキャッシュ/メモリにあり)、プロセスPによって実行されています 連続リリースは、/ apps / EXEをまったく新しい実行可能ファイルに置き換えます。 前提1: プロセスP(および古い実行可能ファイルを参照するファイル記述子を持つ他の人)は、メモリ内の古い/ apps / EXEを問題なく使用し続け、そのパスを実行しようとする新しいプロセスが取得されると仮定します新しい実行可能ファイル。 仮定2: ファイルのすべてのページがメモリにマップされていない場合、ファイルのページを置き換えるページフォールトが発生するまで問題はなく、おそらくセグメンテーション違反が発生すると仮定しますか? 質問1: ファイルのすべてのページをvmtouchのようなものでロックすると、シナリオはまったく変わりませんか? 質問2: / apps / EXEがリモートNFS上にある場合、違いはありますか?(私は仮定しない) 2つの仮定を修正または検証し、2つの質問に答えてください。 これが、ある種の3.10.0-957.el7カーネルを備えたCentOS 7.6ボックスであると仮定しましょう。 更新:さらに考えてみると、このシナリオは他のダーティページシナリオと何の違いもないのではないかと思います。 新しいバイナリを書き込むプロセスは、すべてページングされているため、すべてのキャッシュページを読み取り、すべてのキャッシュページを取得し、それらのすべてのページがダーティとしてマークされると仮定します。ロックされている場合、参照カウントがゼロになった後、コアメモリを占有する無駄なページになります。 現在実行中のプログラムが終了すると、他のものはすべて新しいバイナリを使用すると思われます。それがすべて正しいと仮定すると、ファイルの一部のみがページインされる場合にのみ興味深いと思います。

2
「tail -f | iconv -fsjis」は何も出力しません
tail -fファイルにしたいのですが、そのコンテンツはsjisエンコードされているため、端末のネイティブ(utf-8)エンコードに変換する必要があります。 私がする時 テール-fx | iconv -fsjis 出力はありません。なので テールx | iconv -fsjis 作業は、最初に私にそれがバッファリングの問題だと思ったが、しようとしないunbufferとstdbufに記載されているように、パイプにバッファリングをオフにすることは助けにはなりませんでした。 実際、10kを超えるデータがxに追加された後でも、出力はないため、バッファリングの問題ではないと思います(間違っていない場合、バッファは4kです)が、iconvはEOFを受け取ります。 sjisでエンコードされたファイルをどのようにテールフォローできますか?
14 tail  buffer 


5
パイプラインで無制限の量のデータをバッファリングするユーティリティ?
パイプラインに固執して読み取りと書き込みの速度を分離できるユーティリティはありますか? $ producer | buf | consumer 基本的に、buf可能な限り高速に入力を読み取り、メモリに保存して、可能な限り高速で実行しconsumerながら甘い時間を過ごすことができるユーティリティが必要ですproducer。
13 pipe  io  buffer 

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.