アプリサーバーとしてウェイトレスを使用し、Webサーバー（プロキシ）としてIISを使用して、WindowsでPyramidアプリケーションを実行しています。アプリケーションを実行すると、停止する前に（一見）ランダムな時間動作します。一度に数日、場合によっては数週間かかることがあり、その後停止するだけで、IISは502エラーをスローします。それが停止したとき、Windowsを再起動する以外にそれを再起動する方法はありません。
これは、APSchedulerを使用していくつかのAPIをヒットし、eBay/Amazon間で在庫を同期する小さなアプリケーションです。ログにエラーが表示されていないため、この問題の原因は完全にはわかりません。古いバージョンのアプリケーションを（APSchedulerなしで）実行していましたが、この問題は発生しなかったため、APSchedulerに関係していると思います。
他の誰かがこれを経験しましたか？
まず、私はまだAPSchedulerを使用しておらず、WindowsとIISでPythonサーバー（または実際には他の何か）を実行することについてほとんど知識がありません。
ですから、ここでしか推測できませんが、あなたの問題はある意味でAPSchedulerに関連していることは明らかです。APSchedulerがバックグラウンドタスクに使用するスレッドで問題が発生し、GIL（Pythonのグローバルインタープリターロック）が原因で、スレッドがハングするとアプリケーション全体がダウンすることが想像できます。これは、たとえば、スレッドがある種の競合状態に遭遇したときに発生する可能性があります。たぶん、前の反復が処理を終了する前に処理が開始されることがあります。または、非常に大きなバックログが発生し、処理開始時に問題が発生します。
とにかく、タスクキューは個別に実行され、Webサーバーのコンテキスト外で実行されるため、Webアプリケーションのバックグラウンド処理にはるかに適していると思います。何らかのユーザーアクションによってトリガーされるとすぐにタスクをスケジュールできます。タスクは、ワーカーが利用可能になるとすぐに処理され、特定の時点まで延期されません。Celery
を試してみる
ことをお勧めしますが、他にも利用可能なソリューションがあり、その多くはRedisに基づいています。
Celeryは非常に強力で、定期的なタスクやcrontabスタイルのスケジュールなどの高度な機能を備えているため、APSchedulerを使用して現在行っていることを実行できる可能性があります。
これは、WindowsでCeleryをセットアップするのに非常に役立ちました：http：//mrtn.me/blog/2012/07/04/django-on-windows-run-celery-as-a-windows-service/
これも役立つ場合があります：
Celery Windowsサービスを作成する方法は？
注：選択肢があればLinuxを使用しているので、私はこれらのいずれも試していません。
APSchedulerを正しく動作させることもおそらく可能ですが、ワーカーで問題が発生した場合、バックグラウンドスレッドで発生した問題よりもはるかに簡単にデバッグできるため、Celeryを使用する方がはるかに簡単だと思います。Celeryは、エラーが発生した場合に自動的に電子メールを送信するように構成することもできます。