Privateerに迅速な返信とアドバイスをありがとう。
あなたの答えを見る前に、私はそれを回避する方法を見つけました。これは、何千もの古いcronジョブを削除するためのステップバイステップの方法であり、他の誰かに役立つかもしれません。
phpMyAdminにログオンしました。データベースをクリックしてから「検索」タブをクリックしました。「cron」と入力し、「すべてのテーブル」を選択して「実行」をクリックしました。検索結果リストをwp_optionsテーブルまでスクロールダウンしました。「参照」をクリックしました。リストの一番上にはoption_name 'cron'がありました。「編集」をクリックして、ページがロードされるのを待ちました。cronジョブのリストが表示されているボックスをクリックしました。cronリストが長すぎたため、カーソルが応答するまでに約80秒かかりました。次に、キーボードのCtrl-Aを使用してすべてを選択してから、削除ボタンを押しました。ブラウザーが削除を完了するまでに約2分かかりました(クロムがタイムアウトになったため、動作するFirefoxを試しました)。
さらに数分後、現在アクティブなプラグインのcronジョブがリストに再入力されました。9個のcronジョブがありました(29,000を超える!)。不適切にコーディングされたプラグインからの6年間のcronジョブの複製。そのうちのいくつかは試してみるために1日だけインストールしました。また、Wordfence、BackupBuddy、Nextgen Gallery、AutoOptimizerなどの一般的なプラグインからも数百もの-私はすべて過去にアンインストールしました。ターボチャージされたように私のサイトはロードされます。管理領域ははるかに高速です。管理タイムアウトエラーがなくなりました。ロード時間を短縮しようとして、ウェブサイトの最適化に多くの時間を費やしていました。ホストを移動し、ホスティングプランをアップグレードしました。古いcronジョブをすべて削除するなど、サイトの速度を上げるものはありません。モバイルダウンロード時間は20秒から6秒に短縮されました。
解決策を探してみると、ウェブサイトのパフォーマンスに対するcronジョブの影響に関する情報はほとんど見つかりませんでした。多くの人は、それはほとんど違いがなく、少数のcronジョブについては本当だと言った。しかし、WordPressサイトの誕生から何年も経って、削除されたプラグインからの古いcronジョブが何千とはいなくても、何百と膨れ上がっているのでしょうか。ユーザーにphpのメモリ制限を確認するように依頼する代わりに、致命的なメモリエラーを解決するときに、開発者がまずwp_optionsのcronジョブの数を確認するようにユーザーに依頼することをお勧めします。あなたはあなたが見つけたものに驚き/ショックを受けるかもしれません!:-)