0

問題

大きなテキストフィールドにフィクスチャをロードすると、フィクスチャ処理プロセスがクラッシュし、フィクスチャ（.yml）ファイルが破損することさえあります。

環境

ruby 1.9.3p194（2012-04-20リビジョン35410）[x86_64-darwin10.8.0]; レール3.2.6; OSX 10.6.8; WebBrick ; およびMySQL― 8 Gb RAM

バックグラウンド

1：私たちのプロジェクトは、定期的に5〜10,000語を超える可能性のある多数の記事を表示します。

2：レコードに割り当てられたエスケープされたコンテンツ（適度なボリュームであっても）は、フィクスチャプロセスをクラッシュさせます。

3：rake db：fixtures：loadは、サブジェクト.ymlファイルでクラッシュし、次のエラー/警告が表示されます。応答本文のコンテンツの長さを判別できませんでした。応答のcontent-lengthを設定するか、Response＃chunked=trueを設定します。

4：この資料を1,000語以下の非常に控えめなサイズのテキストフィールドに分割しても、db：fixtures：loadはサブジェクト.ymlファイルでクラッシュします。

5：  ファイルはクラッシュによって破損することがよくあります。たとえば、空のフィールド割り当てを使用してフィクスチャを最初から再構築できます。見かけの処理量の制限に達するまで、一度に1つのフィールドを追加して処理（db：fixtures：load）できます。これにより、最終的にフィクスチャの読み込みプロセスがクラッシュすると、ファイルの最初の数文字に誤った文字が報告されることがあります。 ; 最後のフィールド割り当てを削除しても、そのファイルは実行されなくなります。

6：実験により、フィクスチャが単一のレコードに割り当てることができるymlには約50kの制限があることが確認されています。複数のレコードに正常に割り当てるymlファイルはたくさんありますが、1つのレコードに5万を超えるファイルを正常に割り当てるものはありません。このエクスペリエンスは、数十のテーブルにわたって均一です。

6.1：たとえば、そのようなしきい値を提案するプリンシパルファイルは、単一のレコードのみを作成します。

6.1.1：  空のフィールドの内容をすべてのテキストフィールドに割り当てると、rake db：fixtures：loadはそのテキストフィールドのないレコードを作成することに成功します。

6.1.2：しかし、その単一のレコードに挿入されるサイズ（k）をフィールドごとに増やすと、50kのしきい値（約）を超えるとすぐに、プロセスがクラッシュして次のエラーが発生します。

レーキが中止されました！Mysql2 :: Error：ストレージエンジンからエラー139を取得しました：INSERT INTO[table_name]

6.1.3：  それでも、MySQLバッファサイズを増やしても問題は解決していません。まったく同じ制限があります。

6.1.3.1：my.cnfのMySQLバッファサイズは次のとおりです。

[mysqld]
key_buffer_size = 256M
max_allowed_packet = 1M
table_open_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 16M

6.1.4：  次のようにwebrick/httpresponse.rbのすべてのインスタンスでチャンクをtrueに設定しました。

def initialize(config)
  @config = config
  @logger = config[:Logger]
  @header = Hash.new
  @status = HTTPStatus::RC_OK
  @reason_phrase = nil
  @http_version = HTTPVersion::convert(@config[:HTTPVersion])
  @body = ''
  @keep_alive = true
  @cookies = []
  @request_method = nil
  @request_uri = nil
  @request_http_version = @http_version  # temporary
  @chunked = true # @chunked = false
  @filename = nil
  @sent_size = 0
end

これらの試みはいずれも問題に影響を与えませんでした。

7：  したがって、1Mを超えるymlファイルの数があるため、単一のレコードに割り当てられたkにしきい値が適用されると推測します。

関連する問題？

8：  他の質問がこれと同じ「応答のコンテンツの長さを設定する」警告/エラーを報告しているのがわかります。しかし、私が読んだインスタンスは、WebBrickでページを表示しているときに発生したエラーを報告しています。これは、私たちの状況ではまったく当てはまりません（ただし、現在WebBrickを使用しています）。Mongrelを使用していたときにも同じ問題が発生しました。しかし、私たちの問題がローカルのRubyWebサーバーに関連しているという証拠はまったく見当たりません。

9：  204_304_keep_alive.patch：Webサーバープロセスに起因するこのエラーの発生に苦しんでいる人々が204_304_keep_alive.patchを適用することによってそれを修正していることもわかります。ただし、特にWebサーバープロセスでエラー状態が発生していないため、このパッチは問題に関連する場合と関連しない場合があります。

10：いくつかのOSXシステム、および以前のRuby 1.8 /Rails2で同じ問題が発生しました。

質問

他の人は、フィクスチャを含む単一のレコードに50kを割り当てている必要があります。

この非常に厄介な問題を克服するために、Ruby / Rails / OSX / MySQL環境で何を構成または変更する必要があるかをすぐに知っている人はいますか？

4

1 に答える 1

0

MySQLは10のテキストフィールドに制限されています

これを征服するためのカーブがありました：

私たちの問題を解決するための私の実験の論理的なコースは、最初に1つの大きなテキストフィールドを14の小さなテキストフィールドに分割しました。

したがって、バッファサイズを増やす前に、元のテキストフィールドを14の個別のテキストフィールドに分割していなかった場合、MySQLのバッファサイズを増やすと、フィクスチャ/挿入の問題が修正されます。14個の適度なサイズのテキストフィールドは、バッファサイズを増やしてもテストに影響を与えないと思いましたが、今日の午後、MySQLが最大10個のテキストフィールドしかサポートしないことを示すMySQLバグレポートを発見しました（同様の問題が発生している実装の場合）。 。たまたま、14個のテキストフィールドのうち11番目を追加したときに、50kのしきい値を超えました。

明確なエラーハンドラーを作成する理由はさらに多くなります... 10個のテキストフィールドの制限を超えると、*バッファースペースが不足するのと同じエラーが発生することもあります。

とにかく、私はこの経験が両方の状況で他の人を導くことを願っています。構成を修正するのに多くの時間があります。

いずれにせよ、経験則は次のとおりです。

  1. MySQLの10テキストフィールドの制限を順守してください。
  2. /etc/my.cnfに十分なバッファサイズをデプロイします。

予備のRAMを使用して、プロジェクトのニーズに合わせて「 my-large.cnf 」を実行しています。

于 2012-10-01T05:27:14.310 に答える