問題タブ [fragmentation]

ネットワークに書き込みを行う Java アプリケーションがあります。764b、+/- 5b の領域でメッセージを書き込んでいます。pcap は、ストリームが IP フラグメント化されていることを示しており、これを説明することはできません。

Linux 2.6.18-238.1.1.el5

トレースは次を示します。

( strace -vvvv -f -tt -o strace.out -e trace=network -p $PID )

ネットワークをキャプチャすると、MTU よりも大きなパケットが表示され、断片化が発生しています。

質問:

1) サーバーが 2 つの sendto() を 1 つの IP パケットにバッチ処理しようとしているように見えますが、これは MTU よりも大きいため、断片化されています。なんで？

2) PID 2046 の strace 出力を見ると、等号 <... sendto resumed> 行の後の数字は、送信されたものの合計ですか? つまり、764b は、ライン 3 とライン 5 の合計で送信されましたか? それとも、1 行あたり 764 バイトが送信されていますか?

3)すべての sendto() 出力をログに記録するために strace に渡すことができるオプションはありますか? 何も見つからないようです..

iPhoneアプリに新しいc++を使用する場合、（手動のメモリ管理を実装せずに）断片化を最小限に抑えるために呼び出しをまったく最適化しますか？たとえば、iPhoneは特別なタイプの仮想メモリをサポートしていると聞きました。

メモリ内に大量のビットマップを持つアプリがあります。それは失敗し続けます

エラー。本当にメモリを使いすぎている可能性があります。メモリ リークが発生している可能性があります。何も悪いことをしていない可能性もあり、ヒープの断片化が私たちの命を奪っています。(Android のガベージ コレクターはライブ ブロックを再配置しないため、メガバイトが解放され、50K を割り当てることができない可能性があります。)

フラグメンテーションを除外する方法はありますか? maxAvail/memAvail のようなものを探しましたが、適切なものは見つかりませんでした。

私のアプリケーションでは、いくつかのダイアログを使用して情報を表示しています。私のアプリケーションのテーマは2年前からTheme.Lightであり、これらのダイアログは最初から常に黒でした。

ICSを使用すると、Googleは考えを変えて、これらのダイアログを白に変えたようです。

私のMotoXoomとGalaxyNexusのスクリーンショットをご覧ください。

その真の断片化を処理するためのベストプラクティスは何ですか？

私は別のレイアウトを作成することを考えていました：layout-v14ですが、将来的にlayout-v15、v-16などを作成する必要がある場合、すぐに夢中になりますか？

または、「v14より低い」と「v14より高い」を区別する方法はありますか？

クラスタ化されたGUIDフィールドとして主キーを持つテーブルがあります。NEWSEQUENTIALID()の代わりにを使用してGUIDを生成して いNEWIDます。残念ながら、このテーブルでは1日あたり約25k〜100kの挿入が見られるため、数時間以内に（デフォルト：クラスター化された）主キーインデックスは99％断片化されます。

もともとNEWIDはシーケンシャルIDを生成する代わりに使用していましたが、テーブルを再作成し、を使用してすべての行を再挿入した場合でもNEWSEQUENTIALID（主キー列のデフォルト値として指定した場合でも）、数回以内に99％程度の断片化が見られます。時間。（現在、このテーブルには約130万件のレコードが含まれています。

GUIDを整数の主キーに置き換えることを考えていましたが、それが機能するかどうかはわかりません。さらに、私たちのチームは今後、整数ではなく主キーにGUIDを使用するため、これを行うのに十分な賛同を得られるとは思いません。

このことを最適化しておくための私のオプションは何ですか？SQL Server Expressを使用しているため、SQL Agentにアクセスできません（したがって、定期的にメンテナンスプランを実行してインデックスを再構築することはできません）。

また、将来のある時点でこのデータベース/テーブルを分割する可能性が非常に高いため（データの量が多いため）、テーブルをマージするためにGUIDが必要になる可能性があります。

また、インデックス付きビューを使用することはできません。これは、結合に巻き戻すのが難しい内部選択があるためです。

対応するサービスもある Android アプリ (アクティビティ) があります。サービスはアクティビティによって開始され、アクティビティが停止しても継続的に実行されるはずです。アクティビティが再び開始されると、サービスにバインドしてクエリを実行できます。

アクティビティが OS によって破棄され、作成されることがあります。これは物事に影響を与えるべきではなく、アクティビティが再作成され、サービスに再びバインドできるようになるはずです。これは基本的に機能します。

でも...

Dalvik VM ヒープとネイティブ ヒープの両方が圧縮されていないため、アクティビティがメモリ不足になり、クラッシュするまでサイズが絶えず増加することがわかりました (合計メモリ使用量は実際には一定であり、リークしていません)。作成プロセス中に多くの割り当てが行われるため、アクティビティを破棄して再作成すると、これはさらに悪化します。

これにより、何度か再起動した後にアクティビティがクラッシュすることがほぼ保証されます。これはそれほど気になりませんが、同じアプリケーションの一部であるため、サービスもクラッシュします。サービスには、クラッシュ中に失われる重要なデータが含まれています。

この問題を解決する方法についての提案に興味がありますか?

サービスをアクティビティから分離する方法はありますか (アクティビティがクラッシュしたときにサービスもクラッシュしないように)、サービスとアクティビティを同じアプリケーション内に保持する方法はありますか?

サービス データを永続化することはできますが、これには DB へのアクセスが多く必要になり、バッテリーの節約にはつながりません。

かなりの量のメモリを使用して複雑なシーンをセットアップする OpenGL Android アプリがあり、これが明らかにヒープの断片化を大幅に引き起こします。メモリ リークはありませんが、断片化によるメモリ不足なしにアプリを破棄して作成することは不可能です。（断片化は間違いなく問題であり、リークではありません）

Android には同じ VM/ヒープでアクティビティを破棄および作成する習慣があり、明らかにアクティビティがクラッシュするため、これは大きな問題を引き起こします。これに対抗する戦略として、次の手法を使用しました。

これにより、アクティビティが終了すると VM が完全にシャットダウンされるため、次にアクティビティが開始されたときにフラグメント化されていない新しいヒープが取得されます。

注: これは「Android のやり方」ではないことは承知していますが、ガベージ コレクターが圧縮されていないことを考えると、ヒープを継続的に再利用することは不可能です。

この手法は実際には一般的に機能しますが、アクティビティが非終了モードで破棄されてから再作成された場合は機能しません。

ヒープの劣化を処理する方法について何か良い提案はありますか?

さらに注意: メモリ消費量を削減することも、実際にはオプションではありません。アクティビティは実際にはそれほど多くのメモリを使用しませんが、ヒープ (およびネイティブ ヒープ) は、おそらく大きなメモリ チャンクが原因で、簡単に断片化されるようです。

sk_buffには、次のフラグメンテーションデータを格納できる場所が2つあります。

断片化を処理するこれら2つの方法の違いは何ですか？

私が次のものを持っているとしましょう：

ヒープにメモリを割り当てる上記のベクトルは、メモリの断片化の原因になりますか？断片化についての私の理解は、より大きく、より短期間の割り当ての間に、小規模で長期的な割り当てがある場合にのみ実際に発生するということです（またはその逆）。

この状況を時期尚早に最適化したくないので、このようなコードの一般的な考え方を聞きたいと思います。さまざまな専門家がスタックに大きなバッファを置くことを推奨していないことを知っています（結局のところ、それがヒープの目的です）。そのため、このようなコードを書くときに最初に考えるのは通常それです。断片化は通常、分析が必要なものです。私の心の状態はここにあるべきですか？