AlphonseTai's Blog

不知道什么时候，vps上面的mysql不启动了，后来果断来了个apt-get upgrade。还是无解，发现mysql.err为空。怎么弄头看不明白。

后来查看/var/log/syslog，发现如下记录:

May 28 07:36:53 emhct mysqld: 160528 7:36:53 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. P$
May 28 07:36:53 emhct mysqld: 160528 7:36:53 [Note] /usr/sbin/mysqld (mysqld 5.5.49-0+deb7u1) starting as process 2208 …
May 28 07:36:53 emhct mysqld: 160528 7:36:53 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future$
May 28 07:36:53 emhct mysqld: 160528 7:36:53 [Note] Plugin ‘FEDERATED’ is disabled.
May 28 07:36:53 emhct mysqld: 160528 7:36:53 InnoDB: The InnoDB memory heap is disabled
May 28 07:36:53 emhct mysqld: 160528 7:36:53 InnoDB: Mutexes and rw_locks use GCC atomic builtins
May 28 07:36:53 emhct mysqld: 160528 7:36:53 InnoDB: Compressed tables use zlib 1.2.7
May 28 07:36:53 emhct mysqld: 160528 7:36:53 InnoDB: Using Linux native AIO
May 28 07:36:53 emhct mysqld: 160528 7:36:53 InnoDB: Initializing buffer pool, size = 128.0M
May 28 07:36:53 emhct mysqld: 160528 7:36:53 InnoDB: Completed initialization of buffer pool
May 28 07:36:53 emhct mysqld: 160528 7:36:53 InnoDB: highest supported file format is Barracuda.
May 28 07:36:53 emhct mysqld: InnoDB: The log sequence number in ibdata files does not match
May 28 07:36:53 emhct mysqld: InnoDB: the log sequence number in the ib_logfiles!
May 28 07:36:53 emhct mysqld: 160528 7:36:53 InnoDB: Database was not shut down normally!
May 28 07:36:53 emhct mysqld: InnoDB: Starting crash recovery.
May 28 07:36:53 emhct mysqld: InnoDB: Reading tablespace information from the .ibd files…
May 28 07:36:53 emhct mysqld: InnoDB: Restoring possible half-written data pages from the doublewrite
May 28 07:36:53 emhct mysqld: InnoDB: buffer…
May 28 07:36:53 emhct mysqld: 160528 7:36:53 InnoDB: ERROR: We were only able to scan the log up to
May 28 07:36:53 emhct mysqld: InnoDB: 16701665280, but a checkpoint was at 16701665306.
May 28 07:36:53 emhct mysqld: InnoDB: It is possible that the database is now corrupt!
May 28 07:36:53 emhct mysqld: 160528 7:36:53 InnoDB: Assertion failure in thread 3064944864 in file fut0lst.ic line 83
May 28 07:36:53 emhct mysqld: InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA

 

mysql居然crash了，后来网上了一下，发现好像是innodb顺坏了，简单扫描了mysql官方文档，看的云里雾里。

最终，把mysql数据库存放目录下的ibdata1、ib_*文件删除后，mysql正常启动。

下面图分别简易说明三种较常用的任务处理线程模型。

 

 

 

先说说为什么会来比较这三种任务线程模型，主要还得来于Chromium和手头工作中实际运用的特定问题；这三种任务线程模型在Chromium base的message_loop中都有过实现，且均用在不同的模块中（尽管message_loop中有大部分代码和boost中很像，或者就说直接拷过来的）。不过还是有必要值得讨论下这三种任务线程模型的特点。

 

• 单一线程循环：

这种模型构造最为简单，除了循环线程外，一般由一个临界、一个事件、和一个可以存放任务的数组或者stl容器组成。

但只可以同一进程内使用，或者经过内存映射后的跨进程通讯（一般没人这么干）。

任何任务的投递均要经历：

1，获取临界

2，往任务池中投递任务

3，激活事件

 

循环线程一般流程：

1，获取临界

2，取出任务池中的任务/等待事件激活

3，处理任务

 

对于循环线程可能会产生态变迁位置：

1，获取临界（虽然临界是用户态对象，但有可能会导致线程挂起等） —>  用户态转内核态

2，等待事件  —>  用户态转内核态

3，事件被激活，线程准备恢复执行    —>  内核态转用户态

 

总结：简单，态切换较少，且可能存在较大的线程时间处于用户态。速度快

 

• 窗口消息：

*对窗口消息了解不是很多，所以这里只说一下仅有的少量了解。

这种模型构造组成：窗口、消息循环线程、其他辅助（例如要传递一个大内存，可能会用到共享内存等）。

特点：了解windows消息机制就可以用，且可以方便的处理一些和windows消息有关的任务，利用窗口消息分发特点可以很容易的划分任务类型。跨进程。

 

任何任务的投递均要经历：

1，获取窗口真实句柄

2，投递消息给窗口

 

循环线程一般流程：

1，等消息

2，取消息

3，分发消息

对于循环线程可能会产生态变迁位置：

1，等消息  —>   用户态转内核态

2，取消息(可能会出现，因为消息队列是用共享内存实现的，不清楚要不要做加锁操作)     ->   用户态转内核态

3，分发消息（可能，由于一些消息是默认windows消息，或者是消息钩子链上的消息，需要把消息丢回消息链上，让其他进程进行处理）    —>  用户态转内核态

 

• iocp：

*对iocp了解不是很多，所以这里只说一下仅有的少量了解。

这种模型构造组成：iocp模型、循环线程、其他辅助。

特点：可以方便的处理io相关的任务，内核态会创建一定量的线程数与用户态对应，需要做多次软中断；可跨进程。

任何任务的投递均要经历：

1，获取完成端口真实句柄

2，投递完成端口事件

循环线程一般流程：

1，等事件

2，取事件

3，处理事件

对于iocp线程可能会产生态变迁位置（实际上不全，因为在内核态还需要进行一次APC级别的软中断，iocp这种模型的一个任务流转过程，中断很频繁。详情请参考深入理解windows）：

1，等事件  —>   用户态转内核态

2，取事件    ->   用户态转内核态

3，处理事件

由于手头有份代码，当初的作者可能为了简单或者什么原因，借鉴了boost的iocp模型，并形成一个单线程的底层驱动模型。

早在一年前，刚好要在这个模型上面添加一个及时性要求比较的功能时，发现任务处理的及时性不稳定。有时候任务处理很及时，有时候任务处理延时很重。每个任务的消耗都尽量保持在一个相对平均的水平。

在该模型中频繁堆叠较重的任务后，发现原来是该模型任务处理性能不稳定（被测电脑也是个性能较差的电脑）。后来将及时性任务从该框架中剥离出来以后，问题得到了较好的缓解。

最近在boost，刚好手里有代码，就做个简单的测试。简易代码在这

其中77s对应的图是release下iocp模型，空转1亿次的耗时

其中46s对应的图是release下简单线程模型，空转1亿次的耗时

可见如果只是比较简易线程和iocp模型的话，简易线程的性能会比iocp快不少，但由于特定使用情况，也不能过分的教条。