ヒープダンプを使用してヒープの断片化を計算するためのツールがあるかどうか誰かが知っていますか？

ホスト A とホスト B の 2 つのホストがあり、ホスト A が 1500 バイトのパケットを B に送信し、それらの間に 2 つのルーターがあり、最初のリンクの MTU が 800 バイトで、2 番目のリンクの MTU が 500 バイトであるとします。彼ら。

私が理解しているように、パケットは両方ともフラグメント化する必要があります。パケットは 3 つのパケット (2 つの同じサイズのパケットと 1 つの小さいパケット) にフラグメント化する必要があります。

次に、この 2 番目のルーターに到達すると、最初の 2 つのフラグメント化されたパケットがそれぞれもう一度フラグメント化されます。最初の 2 つの元のフラグメントは、1 つの大きなフラグメント (500 バイトに近い) と、1 つの小さなフラグメントを生成します。

これは私が混乱しているところです。

「More Fragment」ビットは、パケットが「More Fragment」が 0 に設定された次のパケットまでのフラグメントの一部であることを示す最後のものを除いて、最初の 3 つのフラグメントすべてで 1 に設定する必要があることを知っています。ただし、 、フラグメントの 2 番目のセットについては、よくわかりません。パケットが初めてフラグメント化された場合、最後のフラグメントの「More Fragment」は 0 になりますが、これは実際には元のメッセージの途中にあるフラグメントにすぎないため、1 である必要があると感じています。

より多くの経験を持つ誰かが私のためにこれに光を当ててくれることを願っています. 「More Fragment」ビットは再構成に使用されますか? もしそうなら、フラグメントがフラグメント化されたときに、最後のフラグメントを 0 に設定しないと想像できます。

したがって、アルゴリズムは次のようになります。

ここでの私の仮定は正しいですか？

IPv4 と v6 の両方の PMTUD アプリを作成しています。私はUbuntu 12.04でこれを行っていますが、可能な限りOSに依存しないようにしたいと考えており、そこで問題に遭遇しました。

IPv6 パケットはデフォルトで送信者によって断片化されますが、この動作をオフにする方法がわかりません。IPV6_MTU_DISCOVER や IPV6_DONTFRAG などのソケット オプションをいくつか見つけましたが、これらは linux/in6.h の下で見つかりました。これは、netinet ヘッダー ファミリを使用していて、どちらも netinet/in.h の下にないため、役に立ちません。ただし、IPV6_MTU_DISCOVER はありますのでこれにて。何か不足していますか？

編集：少し明確にさせてください。ソケット (AF_INET6、SOCK_RAW、IPPROTO_ICMPV6) を使用して、サイズが大きすぎるという応答を受け取るようなサイズの ICMPv6 パケットを送信し、その応答からパス MTU を取得します。ただし、パス全体で MTU を真に取得するには、発信デバイスの MTU も考慮に入れる必要があります。

私は miredo を使用して IPv6 をトンネリングしていますが、これには 1280 などの最小サイズの MTU が設定されています。1280 より大きいパケットを送信すると、そのパケットが断片化されます (この動作は Wireshark で観察されました)が、拒否するソケットが必要です。パケットをフラグメント化するのではなく、送信して通知してください。

オブジェクトを絶えず割り当てて解放する、長時間実行されるプロセスがあります。オブジェクトは解放されていますが、RSSメモリの使用量は時間の経過とともに増加します。

発生している断片化の量を計算するにはどうすればよいですか？1つの可能性は、RSS / sum_of_allocationsを計算し、それを指標として使用することです。それでも、分母（sum_of_allocations）を計算する方法を教えてください。

短い背景

こんにちは。現在、SQL Server スタンダード エディションの非常に大きなテーブルでパフォーマンスを向上させる必要がある状況に直面しています。テーブルはトランザクションが重いため、かなり多くのトランザクションが発生することが予想されます。

ソリューション パート 1

Barry King がここで提案したものと同様の戦略を使用して、テーブルをいくつかのパーティションに分割することにしました。そのため、以下のようなテーブルがたくさんあります。

基になるすべてのテーブルを処理するための対応するビューもあります。ここでの問題は、Barry King がブログ投稿で述べているように、ビュー内の一意の ID の処理です。ビューは ID を処理できないため、テーブルに格納する必要があり、ID 機能を利用できません。

ソリューション パート 2

次のように別のテーブルを作成することにより:

そして、このコードを使用して私の手順で：

潜在的な問題

このソリューションの潜在的な問題は、間違った順序で [OriginalTableID] に値を書き込む可能性があることです。

プロセス A がプロセス B の前に開始すると仮定します。プロセス A は、プロセス B よりも前に PartitionIDHelper テーブルから ID を取得します。ただし、プロセス B はより高速であり、プロセス B の前に書き込みを行うため、プロセス A よりも先にクラスター化インデックスに書き込みが行われます。

プロセス A は、順序が正しくないため、インデックス内の「最適な」位置に書き込みません。

考えられる解決策

では、どうすればこれを最もよく解決できますか？2つの戦略が考えられます。

1. 私のクラスタ化されたインデックスが少し順不同であることを受け入れます
2. クラスター化インデックスのために、各テーブルでローカル ID 列を使用します。

考えられる解決策 2 は、順序を格納する以外の目的でその列を使用することは決してないため、悪いパスのように思えます。

Michelle Ufford によるこのブログ投稿 (のほとんど) を読んだ後、私は少し断片化されたクラスター化インデックスに固執する方向に傾いています。データは主にシングルトン クエリによってアクセスされますが、これは挿入速度が重要な OLTP システムであるため、以下の引用は私にとって難しい質問です。

ID 整数列にのみクラスター化インデックスを作成することをお勧めしているわけではありません。断片化は一般的には望ましくありませんが、主に範囲スキャン クエリに影響します。シングルトン クエリでは、大きな影響はありません。範囲スキャン クエリでも、定期的な最適化作業の恩恵を受けることができます。ただし、クラスター化されたキーの増加し続ける属性は考慮すべき事項であり、INSERT 速度が重要な OLTP システムでは特に重要です。

すべてのコメントと提案は非常に高く評価されます!

/ターハー

そのため、私が取っている OS のコースの一環として、メモリ アロケータを実装しました (C の malloc のように)。フリースペースはリンクリストに保存されます。

私の質問は次のとおりです。さまざまな割り当て戦略 (たとえば、最初に適合、最適に適合、最悪に適合) をテストするにはどうすればよいでしょうか。現在、私は事前に定義された回数だけ反復しており、そのたびにサイズが 1 ～ N バイトのブロックを割り当てています。ここで、N は 20000 のようなものです。ブロック。終了する前に、フリーリストを確認し、外部フラグメンテーションを計算します。これが進むべき道なのか、それともこれを行うためのより良いアプローチがあるのか​​ わかりません。

各戦略にランダムなブロック サイズを選択する際の問題の 1 つは、割り当てられたブロック サイズが異なる場合、それらを実際に比較できないことですよね? したがって、代替手段は同じテストを実行することですが、各戦略をテストするときに同じ割り当てサイズを使用し、同じブロックを解放するだけです。

これが混乱しないことを願っています:)

ajaxify-html5.jsを既存のWebページに実装しました。jQuery、ScrollTo、History.jsを使用します。素晴らしいもの、素晴らしい作品。のようなすべてのリンク

必要に応じて、コンテンツウィンドウで開きます。全体は、完璧から離れた1つの問題です。次のような断片化識別子を使用するリンクをクリックすると、次のようになります。

... URLはアドレスバー内で適切に変更されますが、コンテンツには何も起こりません。category？id=5もロードされません。

私が見る限り、これは（ajaxify-html5.jsから）解雇されます：

しかし、statechangeは（同じファイルから）しません：

すべてのURLをサニタイズ（#hashtagを削除）できれば、すべてが機能するだろうと思いました...もちろん、新しくロードされたページをどこに配置するかを除いて<a name="hashtag"></a>。残念ながら、サイトはこれらに大きく依存しています...

私の質問は、断片化識別子と一緒に両方のajaxifyを使用することもできますが、後者は最初の影響を受けませんか？

ブロック サイズが小さいほど、ブロック サイズが大きい場合と比較して、内部の断片化が少なくなります。一般的なブロック サイズ値 (2 の倍数)、つまり 512、1024、または 2048 バイトを使用できる場合、大きなブロック サイズと比較して、小さなブロック サイズでより多くの内部フラグメンテーションを行うことは可能ですか?

次のコードは、HONEYCOMB+ を実行しているデバイスで正常に動作することが確認されています。ただし、Samsung Galaxy Y では、通知が生成されません。

ノート ：

• ログに「投稿キュー通知」が表示されます。
• Android SDK からドローアブルstat_sys_download_doneをプロジェクトにコピーしました。

この問題をデバッグする方法を考えることができません。欠けているものがあるかどうかはわかりません。これを修正するための提案は大歓迎です。

私たちのソフトウェアはアクター モデル システムを実装しており、小さなオブジェクトを頻繁に割り当て/割り当て解除しています。各オブジェクトがメモリ リークなしで破棄されると確信しています。(valgrind と tcmalloc ツールを使用して、ソフトウェアのメモリ リークをチェックしました。リークは見つかりませんでした。)

glibc で malloc を置き換えるために tcmalloc を使用するように変更すると、プロセスが OOM (メモリ不足) によって強制終了されるまでメモリが増加し続けることがわかりました。その後、glibc にも同じ問題があることがわかりましたが、増加率は tcmalloc よりも小さくなっています。

malloc_stats() を使用してメモリ情報を表示しました

最初の実行後 (トップ ショー 0.96G)'

• MALLOC: 960110592 (915.6 MB) ヒープ サイズ
• MALLOC: 15886016 (15.2 MB) アプリケーションで使用中のバイト
• MALLOC: 907419648 (865.4 MB) ページ ヒープの空きバイト数
• MALLOC: 0 (0.0 MB) ページ ヒープでマップされていないバイト
• MALLOC: 27121208 (25.9 MB) 中央キャッシュの空きバイト数
• MALLOC: 151040 (0.1 MB) 転送キャッシュの空きバイト数
• MALLOC: 9532680 (9.1 MB) スレッド キャッシュの空きバイト数
• MALLOC: 14275 スパン使用中
• MALLOC: 27 個のスレッド ヒープが使用中
• MALLOC: 7602176 (7.2 MB) 割り当てられたメタデータ

5回目の同じ実行後（トップショー1.2G）

• MALLOC: 1173131264 (1118.8 MB) ヒープサイズ
• MALLOC: 18001048 (17.2 MB) アプリケーションで使用中のバイト
• MALLOC: 1082458112 (1032.3 MB) ページ ヒープの空きバイト数
• MALLOC: 21168128 (20.2 MB) ページ ヒープでマップされていないバイト
• MALLOC: 37992328 (36.2 MB) 中央キャッシュの空きバイト数
• MALLOC: 252928 (0.2 MB) 転送キャッシュの空きバイト数
• MALLOC: 13258720 (12.6 MB) スレッド キャッシュの空きバイト数
• MALLOC: 17651 スパン使用中
• MALLOC: 27 個のスレッド ヒープが使用中
• MALLOC: 8126464 (7.8 MB) 割り当てられたメタデータ

このようなデータからわかります。5 回目の同じ動作の後、17.2 のみがソフトウェアで使用されます。ただし、tcmalloc は、システムに戻らずに 1.1G のメモリを保持します。もちろん、tcmalloc がそれらのメモリを保持するかどうかは問題ではありません。しかし、OOM によってプログラムが強制終了されると、増加し続けます (実際に使用されるメモリは 1G 未満です)。

ヒープの断片化に関連しているとは思えません。どなたか、私たちと共有できる経験をお持ちですか? https://bugzilla.redhat.com/show_bug.cgi?id=843478と同じ状況だと思い ます

どうもありがとう。