※スペースで区切って複数検索が可能です。※スペースで区切って複数検索が可能です。事象ワークフローオプションなどでファイル書出し申請を行った際に「サーバーに接続できません」というエラーが表示されOKボタンを押下すると、出力したZIPファイルが消えてしまうなど、サーバが応答しない場合は発生時間帯のServer側のログに何らかのエラーが記録されていないかご確認ください。※以下はメールサーバが異常だった時にInterSafeに記録されたログです※導入バージョン、導入先によりフォルダパスが異なる場合があります。10060)のログが記録されている場合、最初に記録された日時を中心に他のLogを確認してください。考えられる原因と対処方法2-1.autovacuumによるサーバーの高負荷PostgreSQLではデータが削除された領域を再利用するため、デフォルトではautovacuumがONになっていますが、大規模環境で利用される場合などでは運用時間帯に実行されるとサーバーの負荷が上がり、処理に支障をきたす場合があります。この場合は、以下の?操作で、autovacuumをOFFにしてください。[データベース]-[ISDB]を選択しメニューバーの[ツール]-[サーバ構成]にてpostgresql.confを選択しautovacuumをoffにします。設定変更後は必ず現在値がoffになっていることを確認します。autovacuumをoffにした場合は、夜間・休日などサーバ負荷が低い時間帯でvacuum処理をスケジュール実行してください。アンチウイルススキャンによるサーバーの高負荷アンチウイルスでは定期的にディスクスキャンを行うものがあります。事象発生時間帯にディスクスキャンが実行されていないかを確認し、負荷の低い時間帯に行うなどご検討ください。F-Secureなどサーバに同居しているアンチウイルスによりサービス起動に問題が発生する場合があります。この場合、以下の対応を行い、改善しないかご確認ください。ドライブ/パスは環境/Verにより変わります。高負荷になることで、ユーザリクエストに応えられない状態になっていると考えられます。この場合は、pg_largeobjectテーブル情報(スクリーンショット)をお送りください。情報はILPサーバが導入されているマシンンのPostgreSQlのPgAdminX(GUI画面)よりご確認いただけます。セキュリティ強化の構成」オフをお試しください。統計情報のテーブルサイズに対し、デットタプル(再利用されない領域)の値が大きい場合、PostgreSQLがautovacuumにより再利用可能な領域に再編を試みますが、日中処理が込み合う時間帯で実行されると今回のような事象になってしまうことが報告されています。この場合は、ひとまず上記1項の手順でautovacuumをOFFにした後DBのバックアップリストアによりDBを再編してください。バックアップリストアについてはFAQ:3685をご参照ください。10060」)発生時に以下のようなスクリプトを発行することで回避可能です。暫定対処としてご利用ください。Windows等のサーバー監視ツールをご利用ください。上記に該当しない場合は、以下のログを圧縮してお送りください。ドライブ/パスは環境/Verにより変わります。明らかに関係の無い過去日付のログは除いてください。IRM/FP一般情報この内容は参考になりましたか?はいいいえご回答いただきまして、ありがとうございます。今後の参考にさせていただきます。