自分用GNU socialのタイムラインの反映がとても遅くなって困る

自宅のPCでGNU social(nightly)を動かしているのですが,ふと気づくとタイムラインの最新が30分ほど前になっています.自分の投稿も他のMastodonインスタンスなどに反映されていません.
ログ(config.phpの$config['site']['logfile']で設定してあるもの)を見ると怪しそうなのはこの辺.

2018-02-18 22:46:31 LOG_ERR: [gnusocial.matoken.org:8923.6a16ed84 GET /api/statuses/public_and_external_timeline.json?since_id=312334&count=20] OpportunisticQueueManager: [mirror:Notice 221617] Exception (ServerException) thrown: '[SubMirror] DB_DataObject error []: DB Error: no such table'

DB Error: no such table?最近アップデートもプラグインの追加などもした覚えがないので関係あるかわかりません.連合からの投稿も次々届いているし,遅いながらもタイムラインは更新されているので捌ききれていない?とQueueDaemonを増やしてみました.

daemonを一旦停止して,

$ sudo -u www-data scripts/stopdaemons.sh 

config.phpに以下を追加,

$config['queue']['threads'] = 8;

再度daemonを実行

$ sudo -u www-data scripts/startdaemons.sh 

前(cpu coreから2threadsだった)から変わった感じがしません.vmstatを見ても特に負荷も上がっていないようです.

log levelを上げてみようとconfig.phpに以下を設定してみましたが上のエラーと同じものしか見当たりません.

$config['site']['logdebug'] = true;

mysqlcheck --auto-repairを試しにかけてみましたが変わらず.

そういえばpluginを追加したとき等にカスタムテーブルのチェックをしてくれるscript(checkschema.php)があったなと試してみました.

$ sudo -u www-data scripts/stopdaemons.sh 
$ sudo -u www-data php scripts/checkschema.php
Constraint checking Notice table...
* notice_reply_to_fkey (reply_to => notice.id)
        Found 2 notices with reply_to NOT IN notice.id, reseting...DONE.
* notice_repeat_of_fkey (repeat_of => notice.id)
* notice_profile_id_fkey (profile_id => profile.id)
PHP Warning:  fopen(/var/log/gnusocial.log): failed to open stream: ???????? in /export/data/www/gnusocial.matoken.org/lib/util.php on line 1853
PHP Warning:  fopen(/var/log/gnusocial.log): failed to open stream: ???????? in /export/data/www/gnusocial.matoken.org/lib/util.php on line 1853
  :
PHP Warning:  fopen(/var/log/gnusocial.log): failed to open stream: ???????? in /export/data/www/gnusocial.matoken.org/lib/util.php on line 1853
PHP Warning:  fopen(/var/log/gnusocial.log): failed to open stream: ???????? in /export/data/www/gnusocial.matoken.org/lib/util.php on line 1853
Ensuring no NULL values for foreign keys in QvitterNotification...DONE.
Ensuring no dead profile or notice IDs are stored in QvitterNotification...DONE.
$ sudo -u www-data scripts/startdaemons.sh 

これが当たりだったようでDB errorは消えてタイムラインの流速も戻りました.
原因は不明のままなのがちょっと気持ち悪いですが,バックアップから原因を探すのも面倒なので多分放置です…….

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です