---
title: OpenLM最適要件
description: "## 最適サーバースペック (MariaDB, MySQL, MSSQL共通) ![](https://www.openlm.jp/wp-content/uploads/2024/04/スクリーンショット-2025-03-30-150257-1024x359.png) ## 最適推奨事項 (MariaDB, MySQL, MSSQL共通) - バイナリーログが有効化されている場合、データベースユーザーはアップグレードスクリプトを実行するためにはSUPER権限が必要です。バイナリーログが有効化されているか検証するには、次のコマンドを実行してください: ``` SHOW VARIABLES LIKE 'log_bin'; ``` - 現行ユーザーがSUPER権限を持っているか検証するには、次のスクリプトを実行してください: ``` SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE PRIVILEGE_TYPE = 'SUPER' AND REPLACE(GRANTEE,'''','') = CURRENT_USER(); ``` - ファンクションやプロシジャー作成を次のオプションを有効にして許可してください： log_bin_trust_function_creators. 有効になっているか確認するには次のスクリプトを実行してください。 ```…"
url: "https://www.openlm.jp/docs/openlm-optimization/"
updated: "2025-03-30"
category: システム
---

# OpenLM最適要件

## 最適サーバースペック (MariaDB, MySQL, MSSQL共通)

     ![](https://www.openlm.jp/wp-content/uploads/2024/04/スクリーンショット-2025-03-30-150257-1024x359.png)

## 最適推奨事項 (MariaDB, MySQL, MSSQL共通)

- バイナリーログが有効化されている場合、データベースユーザーはアップグレードスクリプトを実行するためにはSUPER権限が必要です。バイナリーログが有効化されているか検証するには、次のコマンドを実行してください:
  ```
  SHOW VARIABLES LIKE 'log_bin';
  ```
- 現行ユーザーがSUPER権限を持っているか検証するには、次のスクリプトを実行してください:
  ```
  SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE PRIVILEGE_TYPE = 'SUPER' AND REPLACE(GRANTEE,'''','') = CURRENT_USER();
  ```
- ファンクションやプロシジャー作成を次のオプションを有効にして許可してください： log_bin_trust_function_creators.
  有効になっているか確認するには次のスクリプトを実行してください。
  ```
  SHOW VARIABLES LIKE 'log_bin_trust_function_creators';
  ```
- もしレプリケーションが無効であるかポイントインタイムリカバリが必要なければ、別の選択としてバイナリログを無効化するべきです。
- １秒で複数のチェックアウト・チェックインを実行するコンパイラーには、通常より25－50％強いハードウェアを推奨します。
- VMのアドミニストレーターはホストサーバーが要求されるリソースを収納できる事を必ず確認してください。
- DBクエリーで低いパフォーマンスを目にしたら、ディスクキューを確認してください。
- OpenLM Serverと同じデータセンターにデータベースを配置する事を推奨します。
- 下記がMS SQLサーバーへの推奨です。
- 下記にMariaDB / MySQL用にWindows（my.ini）やLinux（my.cnf)のサンプル設定値を提供しましたが、
  データベース管理者（DBA）によって改訂しなければなりません。
- VMネットワークコントローラーは各ネットワークカードで利用可能でなければなりません。
- 大きいデータベース(25GB以上)で大きい負荷の場合、各データベースは3つのファイルと3つのVMディスクコントローラーを、
  データベースファイル、ログファイル、tmpファイル用に持つべきです。

## MariaDB使用の場合の最適チューニング

#### 既存値と推奨値:

         ![](https://www.openlm.jp/wp-content/uploads/2024/04/スクリーンショット-2025-03-30-150624-1024x275.png)

#### 8 RAM の場合に推奨される変更:

     ![](https://www.openlm.jp/wp-content/uploads/2024/04/スクリーンショット-2025-03-30-150645-1024x465.png)

#### 16 RAM の推奨変更:

     ![](https://www.openlm.jp/wp-content/uploads/2024/04/スクリーンショット-2025-03-30-150743-1024x473.png)

#### 24 RAM に推奨される変更:

     ![](https://www.openlm.jp/wp-content/uploads/2024/04/スクリーンショット-2025-03-30-150803-1024x472.png)

#### 期待される効果

- メモリ管理が改善され、MySQL の RAM 不足が防止されます。
- 一時テーブルとメモリを大量に使用する操作が最適化されるため、クエリの実行が高速化されます。
- より効率的な接続処理により、スレッドのオーバーヘッドが削減されます。
- ディスク I/O の使用が最適化され、SSD のパフォーマンスが向上します。

**ここでは、8GB/16GB/24GB RAM を搭載した MariaDB インスタンスで推奨設定がより効率的である理由について詳しく説明します。****説明：**これらの説明はすべて、16GB および 24GB RAM にも適切に当てはまります。

#### **1. innodb_io_capacity**

**なぜ増やすのか？**

この値を増やすと、ストレージに過負荷をかけることなく、InnoDB がより多くのバックグラウンド I/O 操作 (ダーティ ページのフラッシュ、変更バッファのマージなど) を処理できるようになります。

**インパクト：**

- ダーティ ページのフラッシュが高速化 → I/O ボトルネックが軽減され、パフォーマンスが向上します。
- 同時実行性の高いワークロードで高いスループットを維持するのに役立ちます。

#### **2. innodb_open_files**

**なぜ増やすのか？**

- innodb_open_files を高くすると、MariaDB はより多くのテーブル ファイルを開いたままにしておくことができるため、テーブルを繰り返し開閉する必要性が減ります。
- opened_tables が高い場合、innodb_open_files を増やすとファイル システムのオーバーヘッドが軽減されます。

**インパクト：**

- テーブルのオープン/クローズ操作を減らすことにより、クエリのパフォーマンスが向上します。
- 多くのテーブルが頻繁にアクセスされる場合にテーブルのエビクションの問題が発生するのを防ぎます。

#### **3. max_allowed_pa​​cket**

**なぜ減少するのか?**

- たとえば、非常に大きな BLOB または巨大なトランザクションを処理しない限り、max_allowed_pa​​cket=1G は過剰になります。
- パケット サイズが大きいと、クエリに必要ない場合でも、接続ごとのメモリ消費量が増加します。
- 推奨される 256MB は、メモリの浪費を防ぎながら OLTP ワークロードには十分です。

**インパクト：**

- クエリごとの不要なメモリ割り当てが削減され、安定性が向上します。
- 接続が多い環境での過剰な RAM の使用を防ぎます。

#### **4. max_connections**

**なぜ減少するのか?**

- たとえば、8 GB RAM に対して 500 接続は多すぎる可能性があり、不必要なメモリ使用量が発生する可能性があります。
- 各接続は次の目的でメモリを使用します。
  - スレッドバッファ (ソート、結合、読み取りバッファ)
  - 一時テーブル
  - グローバルメモリ割り当て
- サーバーに同時にアクティブなクエリが 500 ある場合、この制限に達する前にメモリが使い果たされる可能性があります。

**インパクト：**

- 過剰なメモリ使用量とスワップの可能性を防ぎます。
- RAM をキャッシュ (InnoDB バッファ プール、クエリ キャッシュなど) に利用できるようにします。
- 必要に応じて、単に接続を増やすのではなく、接続プーリング (ProxySQL、HAProxy など) を使用します。

#### **5. max_heap_table_size**

**なぜ減少するのか?**

- ヒープ テーブル サイズが大きいと、個々のクエリに大量のメモリが割り当てられるため、複数のクエリを実行するとメモリ不足 (OOM) の問題が発生する可能性があります。
- OLTP ワークロードは通常、より小さい結果セットを使用するため、クエリごとに 1GB は過剰です。
- たとえば、RAM が 8 GB の場合、256 MB がより安全な制限であり、1 つのクエリで RAM が過剰に消費されることを防ぎます。

**インパクト：**

- クエリごとの過剰なメモリ割り当てを防止し、安定性を向上させます。
- 一時テーブルの代わりに InnoDB バッファ プールに使用できるメモリを増やします。

#### **6. thread_cache_size**

**なぜ減少するのか?**

- thread_cache_size は、スレッド作成のオーバーヘッドを回避するために MariaDB がキャッシュしておくワーカー スレッドの数を制御します。
- たとえば、8 GB システムでは 500 は過剰であり、キャッシュされたスレッドのメモリ消費量が多くなります。
- 推奨される 200 は、RAM を無駄にすることなく、頻繁に使用されるスレッドをリサイクルするのに十分です。

**インパクト：**

- キャッシュされたスレッドの健全な数を維持しながら、メモリのオーバーヘッドを削減します。
- スレッド作成のオーバーヘッドが問題になる場合は、RAM 8 GB の場合に 200 を超えて増やすことが再検討される可能性があります (16 GB と 24 GB が適切)。

#### **7.** **tmp_table_size**

**なぜ減少するのか?**

- 一時テーブルは並べ替えと結合に使用されます。 tmp_table_size を超えると、MariaDB はそれらをディスクに書き込み、パフォーマンスを低下させます。
- たとえば、 RAM 8 GBの場合クエリごとに  1 GB が多すぎる場合、複数の大きなクエリによって RAM がすぐに使い果たされる可能性があります。
- RAM が 8GB の場合、256MB がより安全な値であり、大量のメモリ消費のリスクを軽減しながら、大規模なメモリ内一時テーブルを使用できます。

**インパクト：**

- 複数の大きな一時テーブルによって OOM エラーが発生するのを防ぎます。
- バッファ プールとクエリ キャッシュに使用できる RAM をより多く確保します。
- ディスク一時テーブルが依然として頻繁に発生する場合は、クエリを最適化するか、RAM が 8 GB の場合は 512 MB に増やします。 RAM が 16GB または 24GB の場合は、適切に増やしてください。

#### **8. innodb_log_file_size**

**現在のデフォルト (手動で変更されていない場合)**

- デフォルト: 100663296 (96MB) ( MariaDB 10.5以上)、50331648 (48MB) (MariaDB 10.4以下)

**なぜ増やすのか？**

- InnoDB は、耐久性とリカバリを確保するために REDO ログ (ib_logfile0、ib_logfile1 など) を使用します。
- ログ ファイルのサイズが大きくなると、ログ ファイルのローテーション頻度が減り、書き込み効率が向上します。
- SSD では書き込みは高速ですが、チェックポイントが頻繁に発生しないようにログ ファイルのサイズを最適化する必要があります。

**推奨値:**

**RAM 8GB → 96MB – 256GB** (書き込みワークロードに応じて、96MB から開始)

**RAM 16GB → 128MB – 512GB** (書き込みワークロードに応じて、128MB から開始)

**RAM 24GB → 256MB – 1GB** (書き込みワークロードに応じて、256MB から開始)

**予想される影響:**

- ログ ファイルのローテーションが減少 → CPU オーバーヘッドが減少。
- クラッシュからの回復が向上 → 障害後の再起動が高速化。
- ディスク書き込みの最適化 → トランザクション ログの効率が向上します。

#### **9. innodb_log_buffer_size**

**現在のデフォルト (手動で変更されていない場合)**

- デフォルト: 16MB

**なぜ増やすのか？**

- ログ バッファーは、コミットされていないトランザクション ログをディスクに書き込む前にメモリに保存します。
- トランザクションに大規模な書き込み (バッチ挿入、更新、削除) が含まれる場合、バッファー サイズが小さいとディスクへの書き込みが頻繁に発生し、遅延が増加する可能性があります。

**推奨値:**

**RAM 8GB → 32MB – 128MB** (トランザクションのサイズに応じて、32MB から開始します)

**RAM 16GB → 48MB – 256MB** (書き込みワークロードに応じて、48MB から開始)

**RAM 24GB → 96MB – 512MB** (書き込みワークロードに応じて、96MB から開始)

**予想される影響:**

- ログバッファのフラッシュ頻度を減らします。
- 大規模なトランザクションのパフォーマンスが向上します。
- ディスク I/O オーバーヘッドを最小限に抑える

## MySQL使用の場合の最適チューニング

#### 既存値と推奨値:

     ![](https://www.openlm.jp/wp-content/uploads/2024/04/スクリーンショット-2025-03-30-152918-1024x230.png)

#### 8GB RAM、4 CPU コア、Windows OS の場合

     ![](https://www.openlm.jp/wp-content/uploads/2024/04/スクリーンショット-2025-03-30-153014-1024x409.png)

#### 16GB 8コア Linux OSの場合:

     ![](https://www.openlm.jp/wp-content/uploads/2024/04/スクリーンショット-2025-03-30-153038-1024x405.png)

#### 16GB 8コア Windows OS:

     ![](https://www.openlm.jp/wp-content/uploads/2024/04/スクリーンショット-2025-03-30-153107-1024x462.png)

#### 24GB 8コア Windows OS:

     ![](https://www.openlm.jp/wp-content/uploads/2024/04/スクリーンショット-2025-03-30-153127-1024x447.png)

**注意：**パスで指定されている MySQL バージョンに注意してください。 (5.7 は非常に古いバージョンです)。
C:/プログラムデータ/MySQL/MySQL サーバー 5.7/データ
システム要件はMySQL8です。

## MS SQL使用の場合の最適チューニング

1. お客様は次のメインテナンス計画を適用する必要があります。
   a) 定期的な統計更新
   b) 定期的なリビルドかインデックスの再組織化
   DBA保持者はOpenLMデータベースにも会社のメインテナンス政策を適用する必要があります。政策等がない場合、公共のパッケージを適用できます([こちらを参照](https://ola.hallengren.com/))
2. （ほぼ）排他的に実行されているWindowsマシンでMSSQLサーバーに割り当てる推奨メモリーはマシンのメモリーの合計の80％を超えてはなりません。
3. OpenLMデータベースは**is_read_committed_snapshot_on**パラメーターを設定しなければなりません。
   設定を確認するには:
   ```
   SELECT is_read_committed_snapshot_on FROM sys.databases
   WHERE name= 'YourDatabase'
   ```
   設定するには:
   ```
   DECLARE @sqlCommand varchar(1000)
   DECLARE @db_name varchar(50)
   SET @db_name = 'YourDatabase'
   SET @sqlCommand = 'ALTER DATABASE ' + @db_name + ' SET ALLOW_SNAPSHOT_ISOLATION ON '
   EXEC (@sqlCommand)
   SET @sqlCommand = 'ALTER DATABASE ' + @db_name + ' SET SINGLE_USER WITH ROLLBACK IMMEDIATE '
   EXEC (@sqlCommand)
   SET @sqlCommand = 'ALTER DATABASE ' + @db_name + ' SET READ_COMMITTED_SNAPSHOT ON '
   EXEC (@sqlCommand)
   SET @sqlCommand = 'ALTER DATABASE ' + @db_name + ' SET MULTI_USER '
   EXEC (@sqlCommand)
   ```
4. より良いパフォーマンスのためには、別の論理ディスク（ある状況下では、物理ディスクでも）にtempdb、データベースとログファイルをインストールすることを推奨します。手堅いインストレーションは
   a) 1- tempdbデータ用ディスク (ssd設定推奨)
   b) 1- システムデータベース用ディスク(msdb、 model、 master)
   c) 1- 全ログ用ディスク(tempdbログ含む)
   d) 1- 全DBデータ用ディスク
5. tempdbはとても重要な役割を持ち、全てのパラメーターや仮テーブルを保持し、ソートや集計を実行します。Tempdbデータファイルの数はプロセッサーの数通りが推奨されます。最大8 (それ以上はパフォーマンスに影響ありません)
6. データベースファイルの自動増幅単位はデフォルトでパーセントに設定されており危険です。MB単位を使用するのが良くて実践的です。レコードサイズで掛け算して予測できる増幅に基づくのが良いです。どの場合でも、ディスクサイズにアラート設定をするのが推奨されます。
7. あらかじめログサイズを設定する事を推奨します。
8. クラッシュから再開したり、ログファイル増幅を制御できる定期的なバックアッププログラムが推奨されます。データベースのシュリンキング（縮小）は実践的には良くなく推奨されません。