InnoDBエンジンを備えたほぼ標準のMariaDBで問題なく動作しましたが、Spider Engine + Sharding/Partitioningをテストしたいと思いました。 15〜20分間、MariaDB InnoDBで問題なく通過するクエリがありました。スパイダーエンジンでは、何をしても、常にメモリ不足になります。スパイダーエンジンを使用したセットアップでは、1つのスパイダーエンジンに2つのバックエンドがあり、両方に適切なパーティションが設定されています。
私が間違っているところ。設定で何を変更すればよいですか。
MariaDB [(none)]> show variables like '%spider%';
+---------------------------------------+-----------+
| Variable_name | Value |
+---------------------------------------+-----------+
| spider_auto_increment_mode | -1 |
| spider_bgs_first_read | -1 |
| spider_bgs_mode | 3 |
| spider_bgs_second_read | -1 |
| spider_bka_engine | |
| spider_bka_mode | 1 |
| spider_bka_table_name_type | -1 |
| spider_block_size | 16384 |
| spider_bulk_size | -1 |
| spider_bulk_update_mode | -1 |
| spider_bulk_update_size | 128000000 |
| spider_casual_read | -1 |
| spider_conn_recycle_mode | 1 |
| spider_conn_recycle_strict | 0 |
| spider_connect_mutex | OFF |
| spider_connect_retry_count | 1000 |
| spider_connect_retry_interval | 1000 |
| spider_connect_timeout | 28000 |
| spider_crd_bg_mode | -1 |
| spider_crd_interval | -1 |
| spider_crd_mode | -1 |
| spider_crd_sync | -1 |
| spider_crd_type | -1 |
| spider_crd_weight | -1 |
| spider_delete_all_rows_type | -1 |
| spider_direct_dup_insert | -1 |
| spider_direct_order_limit | 1 |
| spider_dry_access | OFF |
| spider_error_read_mode | -1 |
| spider_error_write_mode | -1 |
| spider_first_read | -1 |
| spider_force_commit | 1 |
| spider_general_log | OFF |
| spider_init_sql_alloc_size | -1 |
| spider_internal_limit | -1 |
| spider_internal_offset | -1 |
| spider_internal_optimize | -1 |
| spider_internal_optimize_local | -1 |
| spider_internal_sql_log_off | OFF |
| spider_internal_unlock | OFF |
| spider_internal_xa | OFF |
| spider_internal_xa_id_type | 0 |
| spider_internal_xa_snapshot | 0 |
| spider_local_lock_table | OFF |
| spider_lock_exchange | OFF |
| spider_log_result_error_with_sql | 0 |
| spider_log_result_errors | 0 |
| spider_low_mem_read | 1 |
| spider_max_order | 32767 |
| spider_multi_split_read | 1 |
| spider_net_read_timeout | 28000 |
| spider_net_write_timeout | -1 |
| spider_ping_interval_at_trx_start | 3600 |
| spider_quick_mode | 3 |
| spider_quick_page_size | 8096 |
| spider_read_only_mode | -1 |
| spider_remote_access_charset | |
| spider_remote_autocommit | 1 |
| spider_remote_default_database | |
| spider_remote_sql_log_off | 0 |
| spider_remote_time_zone | |
| spider_remote_trx_isolation | -1 |
| spider_reset_sql_alloc | -1 |
| spider_same_server_link | OFF |
| spider_second_read | -1 |
| spider_select_column_mode | -1 |
| spider_selupd_lock_mode | -1 |
| spider_semi_split_read | 8 |
| spider_semi_split_read_limit | 8 |
| spider_semi_table_lock | 1 |
| spider_semi_table_lock_connection | -1 |
| spider_semi_trx | ON |
| spider_semi_trx_isolation | -1 |
| spider_skip_default_condition | -1 |
| spider_split_read | -1 |
| spider_sts_bg_mode | -1 |
| spider_sts_interval | -1 |
| spider_sts_mode | -1 |
| spider_sts_sync | -1 |
| spider_support_xa | ON |
| spider_sync_autocommit | ON |
| spider_sync_time_zone | OFF |
| spider_sync_trx_isolation | ON |
| spider_table_init_error_interval | 1 |
| spider_udf_ct_bulk_insert_interval | -1 |
| spider_udf_ct_bulk_insert_rows | -1 |
| spider_udf_ds_bulk_insert_rows | -1 |
| spider_udf_ds_table_loop_mode | -1 |
| spider_udf_ds_use_real_table | -1 |
| spider_udf_table_lock_mutex_count | 20 |
| spider_udf_table_mon_mutex_count | 20 |
| spider_use_all_conns_snapshot | OFF |
| spider_use_consistent_snapshot | OFF |
| spider_use_default_database | ON |
| spider_use_flash_logs | OFF |
| spider_use_handler | -1 |
| spider_use_pushdown_udf | -1 |
| spider_use_snapshot_with_flush_tables | 0 |
| spider_use_table_charset | -1 |
| spider_version | 3.2.21 |
+---------------------------------------+-----------+
クエリが完全に問題だとは思わない。全体としては、Spider Storage Engine(SSE)ではありません。 SSEには、注意すべき特定の側面が1つあります。各シャードへのDB接続です。
DB接続がメモリを割り当てる方法について考えてみてください。
次に、単一のDB接続に関連付けられているバッファを示します。
与えられたSSEは両方のシャードへの開いた接続を維持する必要があり、何が起こっているかを想像します:
これらの接続の両方がデータの共有を保持している間に、集計が行われています。
DB接続のメモリ消費に関する過去の投稿です
Apr 24, 2012
: DB接続のオープンとクローズにはどれくらいのコストがかかりますか?Apr 25, 2012
: メモリ不足mysqlが中止されましたOct 01, 2014
: キャッシュ内のスレッドはまだメモリを使用していますか?クエリについては、結果全体を生成してから、1,000万行を吸い上げます。 2つのDB接続からのメモリは、クエリが完了するまで解放されない可能性があります。
InnoDBバージョンのデータに対するクエリが機能するのはなぜですか?ほとんどの場合、生成された一時テーブルは最終的にディスクに書き込まれ、結果セット全体の処理を続行します。これはすべて1つのDB接続で行われます。
DB接続をディスクに移動させるか、RAMの容量を4倍にするために、いくつかのバッファサイズを下げる必要がある場合があります。それらの調整に少し時間をかけてください。
もう1つ:ビューに対して集計すると、必ず大きな一時テーブルが作成されます。 InnoDBの場合でも、クエリをリファクタリングして、取得する行数を減らしてください。