ホームページ  >  記事  >  バックエンド開発  >  HTMLレンダリング関数のメモリリーク

HTMLレンダリング関数のメモリリーク

王林
王林転載
2024-02-06 10:39:11621ブラウズ

html 渲染函数内存泄漏

質問の内容

私が直面している問題は、わずか 200 件のリクエストを試行しただけでも、プログラムがコンテナーのメモリの 6GB を占有し、結局はオームキルになります。 私のアイデアは、html に存在するすべてのテキスト ノードを抽出し、それらを処理して名前、html、およびそのタグのテキストを抽出することです。したがって、特定のタグの HTML を生成するには、golang.org/x/net/html の render 関数を使用します。ここで、生成された HTML を書き込むための io.writer として strings.builder を指定します。しかし、何らかの理由で、ビルダーはメモリを大量に消費します。

リーリー

URL の特定のリストが必要な場合は、ここにあります。一度に60件くらいのリクエストをしました。

bytes.buffer bytes.buffersync.pool を使用してみましたが、どちらも同じ問題が発生します。 pprof を使用すると、strings.builder の writestring メソッドが大量のメモリ使用量を引き起こしていることに気付きました。


正解


したがって、ここでの基本的な質問は、任意の コンテンツ タイプ を受け入れることです。これは、ほとんどの Web サイトでクロールの観点から受け入れられません。 text/html を送信する必要があります。

問題は、url が HTML データ golang.org/x/net/html を表さないものを送信しても、エラーをスローせずに受け入れられることです。

application/pdf が返され、本文には解析された PDF のバイナリ データである html.Parse が含まれ、エラーは返されない例を考えてみましょう。これは次のとおりです。受け入れられたバイナリ データをスクレイピング/クロールするための奇妙な動作ライブラリ。

解決策は次のとおりです: 応答ヘッダーを確認し、データが HTML のみの場合は続行します。そうでない場合は、あいまいさがあるか、メモリ使用量が増加します (おそらく減少します)。ただし、何が起こるかは予測できません。起こることが起こる。

以上がHTMLレンダリング関数のメモリリークの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事はstackoverflow.comで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。