现象：magento2站点，查看系统负载，在4.5左右。
尝试：在top命令详情中，mysqld和php进程占用CPU、内存高。先删除magento的定时任务，再手动退出当前的php任务进程，系统负载明显回落。但将定时任务加回后，负载又升高。最后，将数据库中的cron_schedule清空，即执行 TRUNCATE cron_schedule; 后，基本恢复正常。

参考：https://magento.stackexchange.com/questions/203107/magento-2-cron-schedule-table-increasing-and-cpu-100

问题：在 debian 11 里安装了 strongswan 5.9.8-3，但Windows 10无法以ikev2方式连接，提示策略错误。查看 debian 的日志，部分内容如下：

debian charon: 13[IKE] x.x.x.x is initiating an IKE_SA debian charon:
13[CFG] received proposals:
IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
IKE:3DES_CBC/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
IKE:AES_CBC_192/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
IKE:AES_CBC_192/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
IKE:AES_CBC_192/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
IKE:AES_GCM_16_128/PRF_HMAC_SHA1/MODP_1024,
IKE:AES_GCM_16_128/PRF_HMAC_SHA2_256/MODP_1024,
IKE:AES_GCM_16_128/PRF_HMAC_SHA2_384/MODP_1024,
IKE:AES_GCM_16_256/PRF_HMAC_SHA1/MODP_1024,
IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_1024,
IKE:AES_GCM_16_256/PRF_HMAC_SHA2_384/MODP_1024 debian charon: 13[CFG]
configured proposals:
IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/AES_CTR_128/AES_CTR_192/AES_CTR_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/CAMELLIA_CTR_128/CAMELLIA_CTR_192/CAMELLIA_CTR_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/AES_XCBC_96/AES_CMAC_96/HMAC_SHA1_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA1/CURVE_25519/CURVE_448/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048,
IKE:AES_CCM_16_128/AES_CCM_16_192/AES_CCM_16_256/AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/CHACHA20_POLY1305/AES_CCM_8_128/AES_CCM_8_192/AES_CCM_8_256/AES_CCM_12_128/AES_CCM_12_192/AES_CCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA1/CURVE_25519/CURVE_448/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048

尝试：在 /etc/ipsec.conf 配置文件中，用 ike = 3des-aes128-aes192-aes256-sha1-sha256-sha384-modp1024 降低加密级别。

参考：https://docs.strongswan.org/docs/5.9/interop/windowsClients.html

问题：华为云的机子，使用了debian 10.0的系统模板。执行 apt update 和 apt upgrade 且重启系统后，cat /etc/debian-release 还是 10.0。

尝试：原来提示 The following packages have been kept back: base-files ，那么再次执行 apt-get install base-files 后，就可以查看到新的版本号了(10.13)。

参考：https://askubuntu.com/questions/601/the-following-packages-have-been-kept-back-why-and-how-do-i-solve-it

问题：iRedMail 的邮局用户，收取不到 netflix 的邮件。日志显示 queue file size limit exceeded 。

尝试：注释 /etc/postfix/main.cf 里的一行 message_size_limit =8640 。原因可能是 iRedMail 的邮件大小默认值过小。注释掉后，posfix的默认值是 10240000 (10MB)。

参考：

• https://www.postfix.org/postconf.5.html
• https://bobcares.com/blog/postfix-queue-file-size-limit-exceeded/

问题： debian 11默认安装的nginx和php7.4-fpm，在wordpress扫描经sftp上传的图片导到媒体库时，经常提示Ajax错误。nginx错误日志为：upstream timed out (110: Connection timed out) while reading response header from upstream。

尝试：在站点的php配置内容中，适当加大超时时间，如：

fastcgi_read_timeout 600;
fastcgi_send_timeout 600;
fastcgi_connect_timeout 600;

参考：https://stackoverflow.com/questions/59713432/nginx-php-fpm-fastcgi-upstream-timed-out