パフォーマンスガイド

MySQLのチューニング

MySQLデータベースのチューニングを行うことができます。 手順は以下の通りです：

1. <ServiceDesk>\binフォルダに移動します。

2. startdb.batをテキストエディタで開き、以下の内容のうち、搭載メモリに応じた適切なものを、一番最後の行の下に追加します。

搭載メモリが1GBの場合：

--set-variable=query-cache-type=2 --read_buffer_size=128K --read_rnd_buffer_size=1M --sort_buffer_size=1M --myisam_sort_buffer_size=4M --tmp_table_size=32M --max_heap_table_size=32M --key_buffer_size=32M --innodb_buffer_pool_size=128M --bulk_insert_buffer_size=16M --table_cache=512 --thread_cache=32 --innodb_flush_log_at_trx_commit=0 --low-priority-updates

 

搭載メモリが2GBの場合：

--set-variable=query-cache-type=2 --read_buffer_size=128K --read_rnd_buffer_size=1M --sort_buffer_size=2M --myisam_sort_buffer_size=4M --tmp_table_size=32M --max_heap_table_size=32M --key_buffer_size=32M --innodb_buffer_pool_size=256M --bulk_insert_buffer_size=16M --table_cache=512 --thread_cache=32 --innodb_flush_log_at_trx_commit=0 --low-priority-updates

 

搭載メモリが3GBの場合：

--set-variable=query-cache-type=2 --read_buffer_size=128k --read_rnd_buffer_size=1M --sort_buffer_size=2M --myisam_sort_buffer_size=8M --tmp_table_size=32M --max_heap_table_size=32M --key_buffer_size=64M --innodb_buffer_pool_size=750M --bulk_insert_buffer_size=16M --table_cache=750 --innodb_flush_log_at_trx_commit=0 --low-priority-updates

 

搭載メモリが4GBの場合：

--set-variable=query-cache-type=2 --read_buffer_size=128K --read_rnd_buffer_size=2M --sort_buffer_size=2M --myisam_sort_buffer_size=8M --tmp_table_size=32M --max_heap_table_size=32M --key_buffer_size=64M --innodb_buffer_pool_size=1024M --bulk_insert_buffer_size=16M --table_cache=900 --innodb_flush_log_at_trx_commit=0 --low-priority-updates

 

上記手順を踏んでもまだパフォーマンスに問題がある場合、以下に示すログファイルを弊社サポートチームが分析するためにお送りください。

1. wrapper.log （<ServiceDesk>\binフォルダ内）

2. serverout0.txt 〜 serverout5.txt （<ServiceDesk>\server\default\logフォルダ内）

データアーカイブ

ServiceDesk Plusのパフォーマンス向上のため、クローズ/解決済みのリクエストデータを一定期間おきにアーカイブするスケジュールが可能です。 リクエストのアーカイブの詳細はデータアーカイブをご確認ください。

分散型資産スキャン

数多くのノード（例えば1,000以上）を持つと、これらのノードを一定期間おきにスキャンすることがServiceDesk Plusの性能低下の原因になり得ます。 サーバ不可を軽減するため、分散型資産スキャンを使用してノードのスキャンを行うことが可能です。 これは、ServiceDesk Plusのリモートサーバをインストールすることで可能となります。 リモートサーバは一定期間おきにノードをスキャンし、そのデータを中央のServiceDesk Plusサーバにエクスポートします。

リクエストカウントの無効化

リクエストカウントとは、リクエストリストビューページにおいて表示される、すべてのリクエストの数の値です。 リクエストカウントの値が増えるとそれに応じ、リストビューページにおいてリクエストを表示するためにかかる時間が長くなります。

リクエストカウントの値は削除できません。 ただし、リクエストカウントをリクエストビューページの行カウントボタンをクリックすることで表示するようにすることが可能です。

行カウントボタンを表示するには、以下のクエリを使用します：

update GlobalConfig set PARAMVALUE='FALSE' where CATEGORY='PERFORMANCE' and PARAMETER='SHOW_REQUEST_COUNT';

リクエスト更新タイマーの無効化

更新タイマーは一定期間おきにリクエストリストビューページを自動更新するものです。 この機能はServiceDesk Plusのパフォーマンス低下を招く可能性があります。

以下のクエリを使用し、リフレッシュタイマーのオプションを無効にすることが可能です：

update GlobalConfig set PARAMVALUE='FALSE' where CATEGORY='PERFORMANCE' and PARAMETER='SHOW_WO_REFRESH_TIME';

すべてのリクエストフィルタの無効化

リクエストリストビューにおける「すべてのリクエスト」フィルタは、リクエストのステータスにかかわらず、これまで作成されたすべてのリクエストを表示します。 リクエストの総数が増加すると、ServiceDesk Plusのパフォーマンスが徐々に低下します。

この場合、以下のクエリを使用して「すべてのリクエスト」オプションをフィルタドロップダウンから削除することが可能です：

update GlobalConfig set PARAMVALUE='FALSE' where CATEGORY='PERFORMANCE' and PARAMETER='SHOW_ALL_REQUEST_VIEW';

リストビューのリクエスト数を減らす

リクエストリストビューにて、1ページに表示するリクエスト数を決定するドロップダウンがあります。 このドロップダウンの選択を25や50にすることで、リクエストのロードにかかる負荷を軽減し、ServiceDesk Plusのパフォーマンスを改善できます。

簡易概要検索の無効化

簡易概要はリクエストリストビューにてリクエストの件名の上をマウスオーバーした際に表示される情報です。 デフォルトでは、検索を行う際にリクエスト毎の簡易概要も検索されます。 しかしデータ量が大きくなると、ServiceDesk Plusのパフォーマンスは徐々に低下します。

以下のクエリを使用し、本機能を無効にすることが可能です：

update GlobalConfig set PARAMVALUE='false' where CATEGORY='SearchShortDescription' and PARAMETER='Status';

最新アイテムリストのクリーンアップ

デフォルトでは、最新アイテムリストは15日ごとに削除されます。 クリーンアップの頻度を上げることにより、ServiceDesk Plusのパフォーマンスを向上させることができます。

例： 5日ごとに最新アイテムリストをクリーンアップする場合、以下のクエリを使用します：

update GlobalConfig set PARAMVALUE=5 where CATEGORY='CLEANUP_TASK' and PARAMETER='CLEANUP_RI_LIMIT';

最新アイテムリストのクリーンアップ周期の最大値は90です。 クリーンアップを無効にしたい場合、パラメータの値を-1に設定します。

エラーログ制限のクリーンアップ

デフォルトでは、エラーログリストは180日ごとに削除されます。 クリーンアップの頻度を上げることにより、バックアップの処理を高速化できます。

例： 30日ごとにエラーログリストをクリーンアップする場合、以下のクエリを使用します：

update GlobalConfig set PARAMVALUE=30 where CATEGORY='CLEANUP_TASK' and PARAMETER='CLEANUP_ERROR_LOG_LIMIT';

エラーログリストのクリーンアップ周期の最大値は365です。 クリーンアップを無効にしたい場合、パラメータの値を-1に設定します。

ACCセッションのクリーンアップ

ACCセッションは、ログイン/ログアウト情報などのセッション情報を含むテーブルです。 これらのエントリはアプリケーション上では使用されず、定期的に削除することによりデータベースのパフォーマンス向上が見込めます。 デフォルトでは、セッション情報は90日ごとに削除されますが、この頻度を上げることで、パフォーマンスを向上します。

例： 30日ごとにACCセッションをクリーンアップする場合、以下のクエリを使用します：

update GlobalConfig set PARAMVALUE=30 where CATEGORY='CLEANUP_TASK' and PARAMETER='CLEANUP_ACC_SESSION_LIMIT';

ACCセッションのクリーンアップ周期の最大値は365です。 クリーンアップを無効にしたい場合、パラメータの値を-1に設定します。

システムが生成した通知の削除

システムが生成した通知は、システムが作成し、送信したメッセージのことです。 全てのシステム通知を削除することも、削除する通知を手動で選択することもできます。

全てのシステム通知を削除するには、以下のクエリを使用します：

delete from notification where senderid=1;

不要な通知を削除するために、通知のタイトルの一覧を取得するには、以下のクエリを使用します：

select notificationtitle from notification limit 100;

例： タイトルに 'has been added to the group' を含む通知を削除する場合、以下のクエリを使用します：

delete from notification where notificationtitle like '%has been added to the group%';

ユーザのキャッシュカウントを増やす

デフォルトでは、キャッシュされるユーザデータオブジェクトの数は500です。 ただしメモリを多く搭載した高性能なマシンでは、この値を大きくしてデータのキャッシュを増やすことにより、応答を速くすることができます。

例： キャッシュカウントを1000にする場合、以下のクエリを使用します：

update GlobalConfig set PARAMVALUE='1000' where PARAMETER='USER_CACHECOUNT';

技術担当者のキャッシュカウントを増やす

デフォルトでは、キャッシュされる技術担当者データオブジェクトの数は300です。 ただしメモリを多く搭載した高性能なマシンでは、この値を大きくしてデータのキャッシュを増やすことにより、応答を速くすることができます。

例： キャッシュカウントを1000にする場合、以下のクエリを使用します：

update GlobalConfig set PARAMVALUE='1000' where PARAMETER='TECHNICIAN_CACHECOUNT';

メッセージIDのキャッシュカウントを増やす

デフォルトでは、キャッシュされるメッセージIDの数は1000です。 ただしメモリを多く搭載した高性能なマシンでは、この値を大きくしてデータのキャッシュを増やすことにより、応答を速くすることができます。

例： キャッシュカウントを2000にする場合、以下のクエリを使用します：

update GlobalConfig set PARAMVALUE='2000' where PARAMETER='MESSAGEID_CACHECOUNT';

メールID/ユーザIDのキャッシュカウントを増やす

デフォルトでは、キャッシュされるメールID/ユーザIDの数は1000です。 ただしメモリを多く搭載した高性能なマシンでは、この値を大きくしてデータのキャッシュを増やすことにより、応答を速くすることができます。

例： キャッシュカウントを2000にする場合、以下のクエリを使用します：

update GlobalConfig set PARAMVALUE='2000' where PARAMETER='EMAIL_USERID_CACHECOUNT';