3、4、5月各跑了一个全程马拉松，感觉确实频繁了一些，有数量没质量，成绩平平甚至还创下一次最差，所以在德国的后面1个多月就不准备再跑全程了，但还想找机会跑半程的试一试，以前除了全程马拉松外，只在武汉参加过两次10公里的比赛，半程马拉松还没有跑过。
看了看两本跑步的小册子，也在网上搜索了一番，决定5月18日去Offenba
跑过终点后，志愿者马上给戴上了奖牌，然后领取了无酒精啤酒和香蕉补给，慢慢走出体育场，沿路还看到一位受伤选手难以走上几步台阶的楼梯，还有累得不行的选手干脆躺在地上休息，我自己也找个有阳光的地方一屁股瘫坐在地上休息，拍了张照片从微信上发给儿子看，儿子评价说像是残疾乞丐，晕啊。
在领取存衣包后，又遇到了在体育场门口喊加油的中国人，原来是哥廷根大学的学生，
到点准时出发，德国这边都是记的净时间，所以出发点不用拥挤，大家自觉根据自己的预计时间找到领跑的兔子站在附近就可以。我这次再次准备跟着4小时的兔子跑，并更严格让自己在前面不要过于兴奋、不要超速。
两位领跑的兔子也按时准点，基本上一路都是匀速，第一个10公里没什么特别好说的，跟着以比平时训练稍微快点的速度跑，不算很难。
4月份的波恩马拉松成绩是4小时23分，比我第一次在厦门的4小时22分还要慢，算是创下最差记录了。赛后有些遗憾，怀疑自己是不是报名太多了，中间间隔太短，也没有恢复和重新训练的时间。不过很早以前就已经报名了5月4日Kassel的马拉松，无论如何也要继续参加，难得到国外来，更难得参加国外的马拉松。
于是四月份从波恩回来后也保持了一定的训练，
硬盘确实是现在服务器或者电脑中虽容易损坏的部件了，我们的Linux服务器上安装了比较多的硬盘，每台上面有8颗硬盘，使用的头1、2年还好，到3、4年就逐步出现问题了，常见的是：
几个月前让同事把国内外服务器上的硬盘全部检查了一遍，将通电时间、报错次数、坏道数量等列出来，对损坏严重的硬盘弃用。
随着硬盘损
最近有外地的一位合作伙伴告诉我，发现我们网站百度无法访问、收录下降、快照不更新。关于百度的一些SEO指标什么我关注都不太多，这几年都以发展外文网站为重点去了，以前的中文网站只要看流量、收入变化不大、还正常就可以，有的时候看到一些下降也认为是正常波动不太关注。
这位朋友反复提醒我多次需要注意，我就仔细看了，百度搜索的site某个网站域名，显示“连通率0%”，进入百度站长平台，发现抓取压力在4月19日左右突然断崖式下降，再用模拟抓取工具，发现PC端和移动端都无法读取我们网站，而且奇怪的是显示的IP都不是我们的IP地址，甚至是错误的、一看就不可能
我们网站内容在不断增加，服务器也越来越多，对于服务器的各项指标的监控也显得更必要了，前两个月开始就让同事来做这方面的巡查工作，也应用了一些技术手段，这两天把前一阵子的巡查报告要到，并进行了一些汇总和分析。
另外，关于服务器性能以及一些瓶颈评价也去找了一些资料，摘录如下：
| 好 |
在升级Drupal网站时需要特别注意曾经对哪些模块进行过更改，我们这里主要修改过的记录一下：
前一阵子写了一篇《俺在德国上网的十八般武艺》和一篇《修改OpenWRT的设置接入802.1X认证的网络》，这个CF-E218N远程Wifi放大器确实帮了我的大忙，可以足不出户就连接上百米以外的WLan。 不过从第一天开始就发现有路由器偶然中断的情况，也就是电脑或者移动终端突然会断网找不到Wifi热点，这时跑过去看路由器，会发现背后几个LED灯在不停闪烁，而正常情况下是显示远程无线信号强弱的。故障间隔时间上不固定，有时十几个小时会断一次，有时几个小时，或者几天，好像是与使用频繁程度有关，网络越繁忙就越容易出故障。偶尔也出现过出问题后路由器自己恢复的情况，但多数情况下 最近在对国内服务器进行硬盘的替换升级的时候，发现有一台服务器把数据库迁移到新硬盘后，以前的老硬盘依然非常繁忙（用iostat检查），仔细查看后，发现有一些MySQL数据库用的InnoDB格式，即使把数据库目录搬迁后，实际数据依然放置在以前的硬盘上。 Drupal 7默认是采用InnoDB数据库引擎以利用其一些独特的特性，但我们的系列网站数据量很大，需要分散放置各子网站的数据库才好，所以我们都是改为使用MyISAM数据库，以前曾经修改过Drupal的Core文件来实现数据库引擎的变更，但这在Drupal系统升级的时候就丢失了，这样导致一些新建网站的数据库表，以及一些 站内搜索2002-2023 v11.7 a-j-e-0 |
