漫笔 - 71  文章 - 0  trackbacks - 0
     摘要: 以下是对相关流程和socket过错码正确处理的小结。一. Socket/Epoll首要遇到的问题:(1) 非堵塞socket下,接纳流程(recv/recvfrom)对过错(EINTR/EAGAIN/EWOULDBLOCK)当成Fatal过错处理,发作频频断连.(2)EPOLLERR/EPOLLHUP事情时,直接调用socket反常处理,发作频频断连.(3)udp socket接纳到size为0数...  阅览全文
m88 188bet uedbet 威廉希尔 明升 bwin 明升88 bodog bwin 明升m88.com 18luck 188bet unibet unibet Ladbrokes Ladbrokes casino m88明升 明升 明升 m88.com 188bet m88 明陞 uedbet赫塔菲官网 365bet官网 m88 help
posted @ 2019-08-14 19:11 长戟十三千 阅览(13) | 谈论 (0)修正 保藏
     摘要: 现在银联选用的办法是LT办法,假如epoll可读(大于某个边缘值),读取需求的数据长度,从epollset中del掉,处理完逻辑之后再参加epollset,假如接纳缓冲区依然有数据,由于是LT办法,会持续告知,重复上述进程(读取需求的长度...),假如不del,则其他线程或许会读取该fd接纳缓冲区数据,因而存在竞赛,选用的办法是在set中暂时del掉淘米结构则选用ET办法,可读(只告知一次,后边不...  阅览全文
posted @ 2019-08-14 19:01 长戟十三千 阅览(1) | 谈论 (0)修正 保藏

开发高功用网络程序时,windows开发者们言必称iocp,linux开发者们则言必称epoll。

咱们都了解epoll是一种IO多路复用技能,能够十分高效的处理数以百万计的socket句柄,比起曾经的select和poll功率巨大发了。

咱们用起epoll来都感觉挺爽,的确快,那么,它究竟为什么能够高速处理这么多并发衔接呢?

原理介绍

先简略回忆下怎样运用C库封装的3个epoll体系调用吧。

1 int epoll_create(int size);     2 int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);     3 int epoll_wait(int epfd, struct epoll_event *events,int maxevents, int timeout);   

运用起来很明晰,

1 首先要调用epoll_create树立一个epoll目标。参数size是内核保证能够正确处理的最大句柄数,多于这个最大数时内核可不保证作用。

2 epoll_ctl能够操作上面树立的epoll,例如,将刚树立的socket参加到epoll中让其监控,或许把 epoll正在监控的某个socket句柄移出epoll,不再监控它等等。

3 epoll_wait在调用时,在给定的timeout时刻内,当在监控的悉数句柄中有事情发作时,就回来用户态的进程。

从上面的调用办法就能够看到epoll比select/poll的优胜之处:

由于后者每次调用时都要传递你所要监控的悉数socket给select/poll体系调用,这意味着需求将用户态的socket列表copy到内核态,假如以万计的句柄会导致每次都要copy几十几百KB的内存到内核态,十分低效。

而咱们调用epoll_wait时就相当于以往调用select/poll,可是这时却不必传递socket句柄给内核,由于内核现已在epoll_ctl中拿到了要监控的句柄列表。

所以,实践上在你调用epoll_create后,内核就现已在内核态开端预备帮你存储要监控的句柄了,每次调用epoll_ctl只是在往内核的数据结构里塞入新的socket句柄。

在内核里,悉数皆文件。所以,epoll向内核注册了一个文件体系,用于存储上述的被监控socket。当你调用epoll_create时,就会在这个虚拟的epoll文件体系里创立一个file结点。当然这个file不是一般文件,它只服务于epoll。

epoll在被内核初始化时(操作体系发动),一起会拓荒出epoll自己的内核高速cache区,用于安顿每一个咱们想监控的socket,这些socket会以红黑树的办法保存在内核cache里,以支撑快速的查找、刺进、删去。

这个内核高速cache区,便是树立接连的物理内存页,然后在之上树立slab层,简略的说,便是物理上分配好你想要的size的内存目标,每次运用时都是运用闲暇的已分配好的目标。

 1 static int __init eventpoll_init(void)      2 {      3     ... ...      4       5     /* Allocates slab cache used to allocate "struct epitem" items */      6     epi_cache = kmem_cache_create("eventpoll_epi", sizeof(struct epitem),      7             0, SLAB_HWCACHE_ALIGN|EPI_SLAB_DEBUG|SLAB_PANIC,      8             NULL, NULL);      9      10     /* Allocates slab cache used to allocate "struct eppoll_entry" */     11     pwq_cache = kmem_cache_create("eventpoll_pwq",     12             sizeof(struct eppoll_entry), 0,     13             EPI_SLAB_DEBUG|SLAB_PANIC, NULL, NULL);     14      15  ... ...     

epoll的高效在于

当咱们调用epoll_ctl往里塞入百万个句柄时,epoll_wait依然能够飞快的回来,并有用的将发作事情的句柄给咱们用户。

这是由于咱们在调用epoll_create时,内核除了帮咱们在epoll文件体系里建了个file结点,在内核cache里建了个红黑树用于存储今后epoll_ctl传来的socket外,还会再树立一个list链表,用于存储预备安排妥当的事情,当epoll_wait调用时,只是调查这个list链表里有没有数据即可。

有数据就回来,没有数据就sleep,比及timeout时刻到后即便链表没数据也回来。所以,epoll_wait十分高效。

而且,一般状况下即便咱们要监控百万计的句柄,大多一次也只回来很少数的预备安排妥当句柄罢了,所以,epoll_wait仅需求从内核态copy少数的句柄到用户态罢了,怎样能不高效?!

那么,这个预备安排妥当list链表是怎样保护的呢?

当咱们履行epoll_ctl时,除了把socket放到epoll文件体系里file目标对应的红黑树上之外,还会给内核中止处理程序注册一个回调函数,告知内核,假如这个句柄的中止到了,就把它放到预备安排妥当list链表里。

所以,当一个socket上有数据到了,内核在把网卡上的数据copy到内核中后就来把socket刺进到预备安排妥当链表里了。

如此,一颗红黑树,一张预备安排妥当句柄链表,少数的内核cache,就帮咱们处理了大并发下的socket处理问题。

履行epoll_create时,创立了红黑树和安排妥当链表,履行epoll_ctl时,假如增加socket句柄,则查看在红黑树中是否存在,存在当即回来,不存在则增加到树干上,然后向内核注册回调函数,用于傍边止事情来暂时向预备安排妥当链表中刺进数据。履行epoll_wait时马上回来预备安排妥当链表里的数据即可。

终究看看epoll独有的两种办法LT和ET。无论是LT和ET办法,都适用于以上所说的流程。差异是,LT办法下,只需一个句柄上的事情一次没有处理完,会在今后调用epoll_wait时次次回来这个句柄,而ET办法仅在榜首次回来。

这件事怎样做到的呢?

当一个socket句柄上有事情时,内核会把该句柄刺进上面所说的预备安排妥当list链表,这时咱们调用epoll_wait,会把预备安排妥当的socket拷贝到用户态内存,然后清空预备安排妥当list链表,

终究,epoll_wait干了件事,便是查看这些socket,假如不是ET办法(便是LT办法的句柄了),而且这些socket上的确有未处理的事情时,又把该句柄放回到刚刚清空的预备安排妥当链表了。

所以,非ET的句柄,只需它上面还有事情,epoll_wait每次都会回来。而ET办法的句柄,除非有新中止到,即便socket上的事情没有处理完,也是不会次次从epoll_wait回来的。

  1 /*     2  * Each file descriptor added to the eventpoll interface will     3  * have an entry of this type linked to the hash.     4  */     5 struct epitem {     6         /* RB-Tree node used to link this structure to the eventpoll rb-tree */     7         struct rb_node rbn;     8         //红黑树,用来保存eventpoll     9             10         /* List header used to link this structure to the eventpoll ready list */    11         struct list_head rdllink;    12         //双向链表,用来保存现已完结的eventpoll    13             14         /* The file descriptor information this item refers to */    15         struct epoll_filefd ffd;    16         //这个结构体对应的被监听的文件描述符信息    17             18         /* Number of active wait queue attached to poll operations */    19         int nwait;    20         //poll操作中事情的个数    21             22         /* List containing poll wait queues */    23         struct list_head pwqlist;    24         //双向链表,保存着被监督文件的等候行列,功用类似于select/poll中的poll_table    25             26         /* The "container" of this item */    27         struct eventpoll *ep;    28         //指向eventpoll,多个epitem对应一个eventpoll    29             30         /* The structure that describe the interested events and the source fd */    31         struct epoll_event event;    32         //记载发作的事情和对应的fd    33            34         /*    35          * Used to keep track of the usage count of the structure. This avoids    36          * that the structure will desappear from underneath our processing.    37 */    38         atomic_t usecnt;    39         //引证计数    40             41         /* List header used to link this item to the "struct file" items list */    42         struct list_head fllink;    43         双向链表,用来链接被监督的文件描述符对应的struct file。由于file里有f_ep_link,用来保存悉数监督这个文件的epoll节点    44             45         /* List header used to link the item to the transfer list */    46         struct list_head txlink;    47         双向链表,用来保存传输行列    48             49         /*    50          * This is used during the collection/transfer of events to userspace    51          * to pin items empty events set.    52 */         53         unsigned int revents;    54         //文件描述符的状况,在搜集和传输时用来锁住空的事情调集    55 };    56         57 //该结构体用来保存与epoll节点相关的多个文件描述符,保存的办法是运用红黑树完结的hash表.    58 //至于为什么要保存,下文有具体解说。它与被监听的文件描述符一一对应.    59 struct eventpoll {    60         /* Protect the this structure access */    61         rwlock_t lock;    62         //读写锁    63            64         /*    65          * This semaphore is used to ensure that files are not removed    66          * while epoll is using them. This is read-held during the event    67          * collection loop and it is write-held during the file cleanup    68          * path, the epoll file exit code and the ctl operations.    69 */    70         struct rw_semaphore sem;    71         //读写信号量    72             73         /* Wait queue used by sys_epoll_wait() */    74         wait_queue_head_t wq;    75         /* Wait queue used by file->poll() */    76             77         wait_queue_head_t poll_wait;    78         /* List of ready file descriptors */    79             80         struct list_head rdllist;    81         //现已完结的操作事情的行列。    82             83         /* RB-Tree root used to store monitored fd structs */    84         struct rb_root rbr;    85         //保存epoll监督的文件描述符    86 };    87     88 //这个结构体保存了epoll文件描述符的扩展信息,它被保存在file结构体的private_data    89 //中。它与epoll文件节点一一对应。一般一个epoll文件节点对应多个被监督的文件描述符。    90 //所以一个eventpoll结构领会对应多个epitem结构体。那么,epoll中的等候事情放在哪里呢?见下面    91 /* Wait structure used by the poll hooks */    92 struct eppoll_entry {    93         /* List header used to link this structure to the "struct epitem" */    94         struct list_head llink;    95         /* The "base" pointer is set to the container "struct epitem" */    96         void *base;    97         /*    98          * Wait queue item that will be linked to the target file wait    99          * queue head.   100 */   101         wait_queue_t wait;   102         /* The wait queue head that linked the "wait" wait queue item */   103         wait_queue_head_t *whead;   104 };   105    106 //与select/poll的struct poll_table_entry比较,epoll的表明等候行列节点的结   107 //构体只是稍有不同,与struct poll_table_entry比较一下。   108 struct poll_table_entry {   109         struct file * filp;   110         wait_queue_t wait;   111         wait_queue_head_t * wait_address;   112 };  
posted @ vr虚拟现实 长戟十三千 阅览(10) | 谈论 (0)修正 保藏
768字节,而dynamic格局下,溢出的列只存储前20字节,一旦发作了行溢出, dynamic其实就存储一个指针,数据都放在溢出页里,dynamic代表将长字段(发作行溢出)彻底off-page存储。

Row_format 引发反常的一个事例:
前几天出产MYSQL遇到的一个问题,在录入数据时,整行数据彻底录不进去,报以下错:

Cause:java.sql.SQLException: com.taobao.tddl.common.exception.TddlException:java.sql.SQLException: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException:Row size too large (> 8126). Changing some columns to TEXT or BLOB or usingROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format,BLOB prefix of 768 bytes is stored inline.; nested exception iscom.ibatis.common.jdbc.exception.NestedSQLException:  

该表是一个产品介绍概况表,有20多个TEXT 字段,刚好碰到了一个产品,每个字段录入的数据都很长,
而mysql 中有了个约束,一个页(这儿pagesize 是16K)有必要至少存2行,也便是说每行的存储长度有必要小于等于8192,而这么多 TEXT 字段,一行肯定是存不下来,也便是会发作溢出,而即例发作溢出,每个列依然会存储前768字节(该表的row_formart 是compact),字段一多仍是超过了8192,于是就报错,插不进了。
终究将表的row_format 改为 dynamic 得以处理。alter table … row_format=dynamic;

所以,假如咱们遇到一些表TEXT 或 VARCHAR 大字段许多,又欠好拆解时,或许需求考虑下溢出后列的长度了,假如溢出后列的长度仍是太大,则要看一下表的 row_format :

show table status like '%xxx%'\G  

必要时需求将其实设置为 dynamic 如:

create table test(id int,name text,...... ) row_format=dynamic; 或 alter table test row_format=dynamic;
posted @ 2019-08-14 15:38 长戟十三千 阅览(5) | 谈论 (0)修正 保藏

记住一次面试中,面试官问我是否知道表的紧缩,这个时分我才知道mysql有个表紧缩这么个功用,今日试用下看看表的紧缩率怎样样。

这儿分两个部分阐明,榜首部分:官方文档阐明;第二部分:具体实例测验。

【榜首部分】

一、表紧缩概述:

表紧缩能够在创立表时敞开,紧缩表能够使表中的数据以紧缩格局存储,紧缩能够显着进步原生功用和可伸缩性。紧缩意味着在硬盘和内存之间传输的数据更小且占用相对少的内存及硬盘,关于辅佐索引,这种紧缩带来愈加显着的优点,由于索引数据也被紧缩了。紧缩关于硬盘是SSD的存储设备尤为重要,由于它们相对一般的HDD硬盘比较贵且容量有限。

咱们都知道,CPU和内存的速度远远大于磁盘,由于关于数据库服务器,磁盘IO或许会成为重要资源或许瓶颈。数据紧缩能够让数据库变得更小,然后削减磁盘的I/O,还能进步体系吞吐量,以很小的本钱(消耗较多的CPU资源)。关于读比重比较多的运用,紧缩是特别有用。紧缩能够让体系具有满意的内存来存储热数据。

在创立innodb表时带上ROW_FORMAT=COMPRESSED参数能够运用比默许的16K更小的页。这样在读写时需求更少的I/O,关于SSD磁盘更有价值。

页的巨细通过KEY_BLOCK_SIZE参数指定。不同巨细的页意味着需求运用独立表空间,不能运用体系同享表空间,能够通过innodb_file_per_table指定。KEY_BLOCK_SIZE的值越小,你取得I/O优点就越多,可是假如由于你指定的值太小,当数据被紧缩到不满意满意每页多行数据记载时,会发作额定的开支来重组页。关于一个表,KEY_BLOCK_SIZE的值有多小是有严厉的约束的,一般是依据每个索引键的长度。有时指定值过小,当create table或许alter table会失利。

在缓冲池中,被紧缩的数据是存储在小页中的,这个小页的实践巨细便是KEY_BLOCK_SIZE的值。为了提取和更新列值,mysql也会在缓冲池中创立一个未紧缩的16k页。任何更新到未紧缩的页也需求从头写入到紧缩的页,这时你需求估量缓冲池的巨细以满意紧缩和未紧缩的页,尽管当缓冲空间缺乏时,未紧缩的页会被挤出缓冲池。在下次拜访时,不紧缩的页还会被创立。

二、运用表的紧缩

在创立一个紧缩表之前,需求启用独立表空间参数innodb_file_per_table=1;也需求设置innodb_file_format=Barracuda,你能够写到my.cnf文件中不需求重启mysql服务。

SET GLOBAL innodb_file_per_table=1; SET GLOBAL innodb_file_format=Barracuda; CREATE TABLE t1  (c1 INT PRIMARY KEY)   ROW_FORMAT=COMPRESSED    KEY_BLOCK_SIZE=8;
  • 假如你指定ROW_FORMAT=COMPRESSED,那么能够疏忽KEY_BLOCK_SIZE的值,这时运用默许innodb页的一半,即8kb;
  • 假如你指定了KEY_BLOCK_SIZE的值,那么你能够疏忽ROW_FORMAT=COMPRESSED,由于这时会主动启用紧缩;
  • 为了指定最合适KEY_BLOCK_SIZE的值,你能够创立表的多个副本,运用不同的值进行测验,比较他们的.ibd文件的巨细;
  • KEY_BLOCK_SIZE的值作为一种提示,如必要,Innodb也能够运用一个不同的值。0代表默许紧缩页的值,Innodb页的一半。KEY_BLOCK_SIZE的值只能小于等于innodb page size。假如你指定了一个大于innodb page size的值,mysql会疏忽这个值然后发作一个正告,这时KEY_BLOCK_SIZE的值是Innodb页的一半。假如设置了innodb_strict_mode=ON,那么指定一个不合法的KEY_BLOCK_SIZE的值是回来报错。

InnoDB未紧缩的数据页是16K,依据选项组合值,mysql为每个表的.ibd文件运用1kb,2kb,4kb,8kb,16kb页巨细,实践的紧缩算法并不会受KEY_BLOCK_SIZE值影响,这个值只是决议每个紧缩块有多大,然后影响多少行被紧缩到每个页。设置KEY_BLOCK_SIZE等于16k并不能有用的进行紧缩,由于默许的innodb页便是16k,可是关于具有许多BLOB,TEXT,VARCHAR类型字段的表或许会有作用的。

三、InnoDB表的紧缩优化

 在进行表紧缩时需求考虑影响紧缩功用的要素,如:

  • 哪些表需求紧缩
  • 怎样挑选紧缩表的页巨细
  • 依据运转时功用特征是否需求调整buffer pool巨细,如体系在紧缩宽和紧缩数据所花费的时刻量,体系负载更像一个数据仓库仍是OLTP事务性体系。
  • 假如在紧缩表上履行DML操作,由于数据散布的办法,或许导致紧缩失利,这时你或许需求装备额定的更高档的装备选项

1、何时用紧缩表

一般来说,关于读远远大于写的运用以及具有合理数量的字符串列的表,运用紧缩作用会更好。

2、数据特性及紧缩率

影响数据文件紧缩功率的一个关键要素是数据自身的结构,在块数据中,紧缩是通过辨认重复字符进行紧缩的,关于彻底随机的数据是一个糟糕的状况,一般来说,有重复数据的紧缩更好。关于字符串的列紧缩就不错,无论是string仍是blob、text等类型的。另一方面,假如表中的数据是二进制类型,如整形、浮点型等或许之前别紧缩过的如jpg、png类型的,紧缩作用一般欠好,但也不是肯定的。

为了决议是否对某个表进行紧缩,你需求进行试验,能够比照未紧缩与紧缩后的数据文件的巨细,以及监控体系关于紧缩表的作业负载进行决议。具体试验请查看第二部分。

查看监控紧缩表的负载,如下:

  • 关于简略的测验,如一个mysql实例上没有其他的紧缩表了,直接查询INFORMATION_SCHEMA.INNODB_CMP表数据即可,该表存一些紧缩表的数据状况,结构如下:
Column nameDescription
PAGE_SIZE选用紧缩页巨细(字节数).
COMPRESS_OPSNumber of times a B-tree page of the size PAGE_SIZE has been compressed. Pages are compressed whenever an empty page is created or the space for the uncompressed modification log runs out.
COMPRESS_OPS_OKNumber of times a B-tree page of the size PAGE_SIZE has been successfully compressed. This count should never exceed COMPRESS_OPS.
COMPRESS_TIMETotal time in seconds spent in attempts to compress B-tree pages of the size PAGE_SIZE.
UNCOMPRESS_OPSNumber of times a B-tree page of the size PAGE_SIZE has been uncompressed. B-tree pages are uncompressed whenever compression fails or at first access when the uncompressed page does not exist in the buffer pool.
UNCOMPRESS_TIMETotal time in seconds spent in uncompressing B-tree pages of the size PAGE_SIZE.
  • 关于精密的测验,如多个紧缩表,查询INFORMATION_SCHEMA.INNODB_CMP_PER_INDEX表数据,由于该表搜集数据需求支付昂贵得价值,所以有必要发动innodb_cmp_per_index_enabled选项才干查询。一般不要在出产环境下敞开该选项。
  • 还能够针对紧缩运转一些测验SQL看看功率怎样。
  • 假如发现许多紧缩失利,那么你能够调整innodb_compression_levelinnodb_compression_failure_threshold_pct, 和innodb_compression_pad_pct_max参数。

3、数据库紧缩和运用程序紧缩

不需求在运用端和数据库一起紧缩相同的数据,那样作用并不显着而且还消耗许多CPU资源。关于数据库紧缩,是在server端进行的。假如你在刺进数据前通过代码进行数据紧缩,然后刺进数据库,这样消耗许多CPU资源,当然假如你的CPU有许多结余。你也能够结合两者,关于某些表进行运用程序紧缩,而对其他数据选用数据库紧缩。

4、作业负载特性和紧缩率

为了挑选哪些表能够运用紧缩,作业负载是另一个决议要素,一般来说,假如你的体系是I/O瓶颈,那么能够运用CPU进行紧缩与解紧缩,以CPU交换I/O。

四、INNODB表是怎样紧缩的?

1、紧缩算法

mysql进行紧缩是借助于zlib库,选用L777紧缩算法,这种算法在削减数据巨细、CPU运用方面是老练的、强健的、高效的。一起这种算法是无失真的,因而原生的未紧缩的数据总是能够从紧缩文件中重构,LZ777完结原理是查找重复数据的序列号然后进行紧缩,所以数据办法决议了紧缩功率,一般来说,用户的数据能够被紧缩50%以上。

不同于运用程序紧缩或许其他数据库体系的紧缩,InnoDB紧缩是一起对数据和索引进行紧缩,许多状况下,索引能够占数据库总巨细的40%-50%。假如紧缩作用很好,一般innodb文件会削减25%-50%或许更多,而且削减I/O增加体系吞吐量,可是会增加CPU的占用,你可通过设置innodb_compression_level参数来平衡紧缩等级和CPU占用。

2、InnoDB数据存储及紧缩

悉数数据和b-tree索引都是按页进行存储的,每行包含主键和表的其他列。辅佐索引也是b-tree结构的,包含对值:索引值及指向每行记载的指针,这个指针实践上便是表的主键值。

在innodb紧缩表中,每个紧缩页(1,2,4,8)都对应一个未紧缩的页16K,为了拜访紧缩页中的数据,假如该页在buffer pool中不存在,那么就从硬盘上读到这个紧缩页,然后进行解压到本来的数据结构。为了最小化I/O和削减解压页的次数,有时,buffer pool中包含紧缩和未紧缩的页,为给其他页腾出当地,buffer pool会驱赶未紧缩页,只是留下紧缩页在内存中。或许假如一个页一段时刻没有被拜访,那么会被写到硬盘上。这样一来,任何时分,buffer pool中都能够包含紧缩页和未紧缩页,或许只要紧缩页或许两者都没有。

Mysql选用LRU算法来保证哪些页应该在内存中仍是被驱赶。因而热数据一般都会在内存中。

五、OLTP体系紧缩负载优化

一般来说,innodb紧缩关于只读或许读比重比较多的运用作用更好,SSD的呈现,使得紧缩愈加招引咱们,特别关于OLTP体系。关于常常update、delete、insert的运用,通过紧缩表能够削减他们的存储需求和每秒I/O操作。

下面是针对写密布的运用,设置紧缩表的一些有用参数:

  • innodb_compression_level:决议紧缩程度的参数,假如你设置比较大,那么紧缩比较多,消耗的CPU资源也较多;相反,假如设置较小的值,那么CPU占用少。默许值6,能够设置0-9
  • innodb_compression_failure_threshold_pct:默许值5,规模0到100.设置中止点防止昂扬的紧缩失利率。
  • innodb_compression_pad_pct_max:指定在每个紧缩页面能够作为闲暇空间的最大份额,该参数只是运用在设置了innodb_compression_failure_threshold_pct不为零状况下,而且紧缩失利率通过了中止点。默许值50,能够设置规模是0到75.

【第二部分】试验:

仿制代码
#没有设置紧缩前的数据巨细 -rw-rw----. 1 mysql mysql 368M 12月 29 11:05 test.ibd #设置KEY_BLOCK_SIZE=1 (product)root@localhost [sakila]> alter table test KEY_BLOCK_SIZE=1; Query OK, 0 rows affected (14 min 49.30 sec) Records: 0  Duplicates: 0  Warnings: 0  -rw-rw----. 1 mysql mysql 204M 1月  11 21:43 test.ibd      #####紧缩率44.5%
#设置KEY_BLOCK_SIZE=2 (product)root@localhost [sakila]> alter table test KEY_BLOCK_SIZE=2; Query OK, 0 rows affected (9 min 55.60 sec) Records: 0 Duplicates: 0 Warnings: 0 -rw-rw----. 1 mysql mysql 180M 1月 12 13:40 test.ibd #####紧缩率51% #设置KEY_BLOCK_SIZE=4 (product)root@localhost [sakila]> alter table test KEY_BLOCK_SIZE=4; Query OK, 0 rows affected (7 min 24.52 sec) Records: 0 Duplicates: 0 Warnings: 0 -rw-rw----. 1 mysql mysql 172M 1月 11 21:09 test.ibd #####紧缩率53.2% #设置KEY_BLOCK_SIZE=8 (product)root@localhost [sakila]> alter table test KEY_BLOCK_SIZE=8; Query OK, 0 rows affected (5 min 16.34 sec) Records: 0 Duplicates: 0 Warnings: 0 -rw-rw----. 1 mysql mysql 172M 1月 11 21:00 test.ibd #####紧缩率53.2% #设置KEY_BLOCK_SIZE=16 (product)root@localhost [sakila]> alter table test KEY_BLOCK_SIZE=16; Query OK, 0 rows affected (2 min 47.48 sec) Records: 0 Duplicates: 0 Warnings: 0 -rw-rw----. 1 mysql mysql 336M 1月 12 13:54 test.ibd #####紧缩率8.6%  
仿制代码

【总结】:通过以上测验可知,当KEY_BLOCK_SIZE的值设置为4或许8时,紧缩作用最好,设置为16作用最差,由于页的默许值16K。一般我是设置为8。

posted @ 2019-08-14 15:31 长戟十三千 阅览(2) | 谈论 (0)修正 保藏
      Row_format: Compressed            Rows: 0  Avg_row_length: 0     Data_length: 8192 Max_data_length: 0    Index_length: 0       Data_free: 0  Auto_increment: NULL     Create_time: 2013-09-27 16:09:51     Update_time: NULL      Check_time: NULL       Collation: utf8_general_ci        Checksum: NULL  Create_options: row_format=COMPRESSED KEY_BLOCK_SIZE=8         Comment: 1 row in set (0.00 sec)
仿制代码

 

No3:


 

发现和innodb_file_format相关的2个参数:

仿制代码
+--------------------------+-----------+ | Variable_name            | Value     | +--------------------------+-----------+ | innodb_file_format       | Barracuda | | innodb_file_format_check | ON        | | innodb_file_format_max   | Barracuda | +--------------------------+-----------+ 3 rows in set (0.00 sec)
仿制代码

官方的解说能够参阅如下的链接:http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_file_format

测验进程中发现,假如是innodb_file_format=barracuda而innodb_file_format_max=antelop,那么在树立紧缩表的时分,max会主动变成barracuda。

仿制代码
localhost.test>show global variables like 'innodb_file_format%'; +--------------------------+-----------+ | Variable_name            | Value     | +--------------------------+-----------+ | innodb_file_format       | Barracuda | | innodb_file_format_check | ON        | | innodb_file_format_max   | Antelope  | +--------------------------+-----------+ 3 rows in set (0.00 sec)  localhost.test>create table test_4(x int) ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; Query OK, 0 rows affected (0.01 sec)  localhost.test>show global variables like 'innodb_file_format%'; +--------------------------+-----------+ | Variable_name            | Value     | +--------------------------+-----------+ | innodb_file_format       | Barracuda | | innodb_file_format_check | ON        | | innodb_file_format_max   | Barracuda | +--------------------------+-----------+ 3 rows in set (0.00 sec)
仿制代码

假如innodb_file_format_check这参数解说的,决议innodb是否会查看同享表空间中的表格局的tag,假如查看敞开,那么当符号的表格局的tag高于innodb能够支撑的表格局,那么innodb会报错,并中止发动。假如支撑,那么会将innodb_file_format_max的值改为这个tag的值。

posted @ 2019-08-14 15:24 长戟十三千 阅览(3) | 谈论 (0)修正 保藏
 处理办法:
vim /etc/my.cnf,依据实践状况进行参数调整:
[mysqld]
max_allowed_packet = 1G
innodb_log_file_size = 30M
innodb_log_buffer_size = 512M
innodb_file_format='Barracuda'


alter table 'role' row_format=dynamic
修正之后,重启mysql服务。 

mysql文档
https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-20.html
In MySQL 5.6.22, the redo log BLOB write limit is relaxed to 10% of the total redo log size (innodb_log_file_size * innodb_log_files_in_group).



# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/5.6/en/server-configuration-defaults.html
# *** DO NOT EDIT THIS FILE. It's a template which will be copied to the
# *** default location during install, and will be replaced if you
# *** upgrade to a newer version of MySQL.

[mysqld]

# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M

# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin

# These are commonly set, remove the # and set as required.
# basedir = .....
# datadir = .....
# port = .....
#server_id = 1
# socket = .....

# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M 
#sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES 
port=3306
basedir=/data/mysql
datadir=/data/mysql/mysqldata
log-error=/data/mysql/log
socket=/tmp/mysqld.sock
server_id=1
back_log=2048
log-bin=mysql-bin 
bind-address=0.0.0.0
character-set-server=utf8
collation-server=utf8_general_ci
skip-external-locking
skip-name-resolve
query_cache_type=0
max_connections=2000
max_connect_errors=1000000
default-storage-engine=INNODB
innodb_buffer_pool_size=12884901888
innodb_concurrency_tickets=5000
innodb_flush_method=O_DIRECT
innodb_io_capacity=2000
innodb_io_capacity_max=4000
innodb_log_buffer_size=1048576
innodb_log_file_size=1048576000
innodb_log_files_in_group=2
innodb_file_format=Barracuda
innodb_file_per_table=ON
innodb_file_format_max=Antelope
innodb_max_dirty_pages_pct=75
innodb_open_files=3000
innodb_additional_mem_pool_size=20M
innodb_sort_buffer_size=8388608
join_buffer_size=262144
key_buffer_size=16777216
preload_buffer_size=32768
read_buffer_size=262144
read_rnd_buffer_size=262144
sort_buffer_size=262144
max_allowed_packet=1073741824
binlog_stmt_cache_size=32768
bulk_insert_buffer_size=4194304
key_buffer=64M
slow_query_log=1
slow_query_log_file=/data/mysql/log
long_query_time=5
sync_frm=ON
max_binlog_size=524288000
sync_binlog=1000
binlog_format=ROW
binlog_cache_size=2097152
expire_logs_days=3
tmpdir=/data/mysql/tmpdir
max_tmp_tables=32
tmp_table_size=262144
open_files_limit=65535
table_definition_cache=512
table_open_cache=100
default_storage_engine=InnoDB
default_tmp_storage_engine=InnoDB
log_queries_not_using_indexes=ON
interactive_timeout=7200
lock_wait_timeout=31536000
wait_timeout=86400
connect_timeout=120
pid_file=/data/mysql/mysqldata/mysqld.pid
slave-skip-errors=1062,1053,1146,1061

[mysql]
port=3306
socket=/tmp/mysqld.sock
default-character-set=utf8
posted @ 2019-08-08 18:11 长戟十三千 阅览(5) | 谈论 (0)修正 保藏
     摘要: attribute是GNU C特征之一,在iOS用的比较广泛.体系中有许多当地运用到. attribute能够设置函数特点(Function Attribute )、变量特点(Variable Attribute )和类型特点(Type Attribute)等.函数特点(Function Attribute)noreturnnoinlinealways_inlinepureconstno...  阅览全文
posted @ 2019-01-26 15:28 长戟十三千 阅览(63) | 谈论 (0)修正 保藏
1.下载并装置python-dev
    sudo apt-get install python-dev
2.下载并解压distcc:
    tar xvf distcc-3.2rc1.tar.bz2
3.装备
    cd distcc-3.2rc1/
    ./configure --prefix=/home/you/distcc-install --disable-Werror
4.装置
    make install
5.运转
    服务端运转 
        export PATH=$PATH:服务端distcc程序途径:服务器编译东西途径
        distcc --deamon --allow 192.168.0.0/16  --job 8 --user nobody
    客户端运转 :
        export PATH=$PATH:客户端distcc程序途径:客户端编译东西途径
        export DISTCC_HOSTS="server_ip1 server_ip2 ..."
        make -j8 CC=distcc
6、cmake
cd build/
CC="distcc cc" CXX="distcc g++" cmake ../cmake/





Other:
一个大型的C/12bet项目的编译十分耗时。distcc和ccache这两个东西能够十分有用地紧缩编译时刻。它们并不是独立的编译器,而是合作 GNU GCC运用(它们的材料清晰阐明并不重视其他编译器)。distcc介绍中说,有人完好编译KDE项目只花费6分钟。可见其凶猛!此外,它们都十分易用,保证几分钟就能上手!

这两个项目的主页:
distcc            http://distcc.samba.org/
ccache            http://ccache.samba.org/
这两个软件的装置没什么好说的,都是规范的"./configure;make;make install"。在Ubuntu上装置更简略:sudo apt-get install distcc ccache。

distcc作业原理:

GCC 编译C/12bet构建一个execualble分为三个阶段:(1)C/12bet预处理(gcc -E);(2)编译(gcc -c);(3)链接(ld)。其间第二阶段是功率瓶颈,特别在指定“-O2”等优化选项时。distcc是一个编译器驱动器。它在"gcc -c"阶段把预处理输出分发到指定的服务器阵列(各服务器监听TCP端口3632)并搜集成果。GNU Make和SCons的"-j"并行编译能够运用distcc来加快编译。

distcc用法:
(1)服务器端以一般用户履行“distccd --daemon --allow 10.0.0.0/16”。这使得distccd承受来自10.0网段的悉数TCP衔接。
留意:distcc文档中说"--allow 0.0.0.0"是承受悉数衔接--这现已过期,实践作用是回绝悉数衔接!
(2)假如工程运用automake机制。
设置DISTCC_HOSTS环境变量。
在configure阶段履行"CC=distcc ./configure"。然后履行"make -j XX"。XX是并发使命数目上限。
(3)假如工程由GNU make办理。
设置DISTCC_HOSTS环境变量。
修正Makefile使得在本来C/12bet编译器称号前加上"distcc ",例如设置CC="distcc arm-linux-gcc"。然后履行"make -j XX"。XX是并发使命数目上限。
(4)假如工程由SCons办理。
修正SConstruct使得在本来C/12bet编译器称号前加上"distcc "。导出环境变量HOME和DISTCC_HOSTS到构建环境(留意SCons不会主动把体系环境变量导出到builder子进程):
 Environment(ENV={'HOME': os.environ['HOME'],'DISTCC_HOSTS': ‘localhost 10.0.0.2’},...)
然后履行"scons -j XX"。XX是并发使命数目上限。


distcc毛病处理:
运转distccmon-gnome。假如在编译期间某个distcc服务器一向不活泼,或许的原因比较多。
distcc服务器的问题或许有
(1) IP地址不可达。
(2) distccd进程没有发动。
(3) distcc客户端IP不在--allow指定的规模内。
(4) distccd监听的3632端口被防火墙屏蔽。
distccd的日志记载在/var/log/messages。必要时查看一下。

客户端的问题或许有:
(1) 一些环境变量没有设置
distcc依靠的环境变量有HOME和DISTCC_HOSTS。
distcc 日志在处理问题时特别有用。默许的过错信息输出在console。还能够设置DISTCC_VERBOSE和DISTCC_LOG环境变量以记载具体的调试信息到一日志文件(这对了解distcc作业进程也十分有用)。参阅distcc和distccd联机帮助。

ccache作业原理:
ccache也是一个编译器驱动器。榜首趟编译时ccache缓存了GCC的“-E”输出、编译选项以及.o文件到$HOME/.ccache。第2次编译时尽量运用缓存,必要时更新缓存。所以即便"make clean; make"也能从中取得优点。ccache是通过细心编写的,保证了与直接运用GCC取得彻底相同的输出。


ccache用法:
很简略,就像上面distcc用法说到的那样,给悉数C/12bet编译器称号前加上"ccache "即可。
ccache还能够把distcc作为后台的编译器。编译器设置为"ccache distcc "+原编译器即可。

从我阅历的两个项目来看,独自运用ccache或distcc(除localhost外只用1台distcc服务器)作用比较显着。可是联合运用distcc和ccache的作用就和仅运用distcc差不多。个人倾向于只运用distcc,多加几台distcc服务器。


用distcc,ccache是两年前,项目完毕的空地,自己拿来玩的。其时是在arm上做的一个很大的工程,其时的PC,只编UI部分就需求3个小时,这也是为什么后来我用散布式编译的原因。那个项目是12bet加adobe的flash,仿iphone做一款很炫的手机,其间UI悉数用flash做,作用很炫,速度就比较差了。后来,我也试过在arm9261(200MHz)上用gnash播映flash,作用的确比较一般。言归正传,仍是来说下散布式编译,其实它的原理很简略,把c文件在本机预编译,然后发到其他主机进行编译,编译的后的o文件再传回本机,终究在本机进行链接。没有看过代码,猜想关于每个编译的c文件对应发作一个编译使命,下发到其他机器或本机,终究完结编译。

咱们的环境是ADS1.2+cygwin,用tcc,tcpp进行编译。distcc,ccache本来是在cygwin上直接装的的,但后来在运用时发现会碰到一些问题。所以从源码编译了。distcc发作的中心文件是.i的格局,tcc无法辨认该文件类型,需求修正源码。就一句话,网上能够搜到的。if(dcc_getenv_bool("DISTCC_KEEP_FILETYPE", 1)).然后,./configure; make; make install。ccache问题是相同的,无法辨认.i文件,修正ccache.c,把中心文件i/ii改为c/cpp,相同的办法装置。

然后要对装置的东西进行装备,我其时的装备如下,10.19.5.0网段的主机都能够做协同编译的主机,当然ads的licence只要20个啦。此处目录设置至关重要,tcc无法辨认cygwin环境,tcc -c /cygdriver/c/a.c,  tcc无法读取文件,过错码为C3052E。运用了cygwin既能够win32的途径,又能够辨认posix途径。
export DISTCC_LOG='/var/log/distcc.log'
export DISTCC_HOSTS='localhost 10.19.5.0/24'
export DISTCC_VERBOSE=1
export DISTCC_SAVE_TEMPS=1
export TMPDIR=' e:/test '
export CCACHE_DIR=e:/test
export CCACHE_PREFIX=distcc
export CCACHE_LOGFILE=e:/test/ccache.log


distccd在没有设置DISTCCD_PATH时,运用体系的PATH作为查找,和makefile里指定的不共同。设置了DISTCCD_PATH,很不可思议,其时是为什么。然后distccd --daemon --allow0.0.0.0/0,任何ip都能够接入,比较简略。

修正makefile,在CC,ARMCC,ARMCPP,TCPP本来的设置前,增加ccache。需求阐明的是,distcc仅为编译器前端,编译器的指定需求distcc 。distcc支撑的编译器有必要能够预编译,也便是常用的gcc -E这样的选项。

终究的测验很简略,自己写makefile,只做".c.o:" ,然后把.o文件链接到工程中就能够了。在手机上仍是能够很好的run起来的。当然验证的作业不是那么简略了,看了下反汇编的代码。一台主机编译的和散布式编译的,没有什么太大的不同,汇编稍有不同,但功用共同。

项目完毕后自己玩的东西,尽管没有用于实践来进步功率,但仍是学到了一些东西。



posted @ 2018-09-08 20:56 长戟十三千 阅览(549) | 谈论 (0)修正 保藏
TcMalloc(Thread-CachingMalloc)是google-perftools东西中的一个内存办理库,与规范的glibc库中malloc比较,TcMalloc在内存分配的功率和速度上要高许多,能够提升高并发状况下的功用,下降体系的负载。
Google-perftools项目的网址为:http://code.google.com/p/google-perftools/,该项目包含TcMalloc、heap-checker、heap-profiler和cpu-profiler共4个组件。在只运用TcMalloc状况下能够不编译其他三个组件。
注:运用线程内存池的办法,在小目标是在内存池中进行分配,运用分配较多的内存空间来优化分配时刻。
完结原理请参阅网址http://goog-perftools.sourceforge.net/doc/tcmalloc.html

简介

TcMalloc是一个由Google开发的,比glibc的malloc更快的内存办理库。一般状况下ptmalloc2能在300ns履行一个malloc和free对,而TcMalloc能在50ns内履行一个malloc和free对。
TcMalloc能够削减多线程程序之间的锁争用问题,在小目标上能到达零争用。
TcMalloc为每个线程独自分配一个线程本地的Cache,少数的地址分配就直接从Cache中分配,而且定时做废物收回,将线程本地Cache中的闲暇内存回来给大局操控堆。
TcMalloc以为小于(<=)32K为小目标,大目标直接从大局操控堆上以页(4K)为单位进行分配,也便是说大目标总是页对齐的。
TcMalloc中一个页能够存入一些相同巨细的小目标,小目标从本地内存链表中分配,大目标从中心内存堆中分配。

装置

Linux下tcmalloc的装置进程如下:
1)  从Google源代码网址上下载源代码包,现在最新版别为2.0;
2)  解紧缩源代码包
# unzip gperftools-2.0.zip          或
# tar zxvf gperftools-2.0.tar.gz
3)  编译动态库
# cd gperftools-2.0
# ./ configure  --disable-cpu-profiler --disable-heap-profiler--disable-heap-checker 
--disable-debugalloc--enable-minimal
参加上面的参数是为了只生成tcmalloc_minimal动态库,假如需求悉数组件,指令如下:
# ./configure
# ./configure -h           用于查看编译选项。
编译和装置:
# make&& make install
运用最小装置时把tcmalloc_minimal的动态库拷贝到体系目录中:
# cplib/tcmalloc_minimal.so.0.0.0 /usr/local/lib
创立软衔接指向tcmalloc:
# ls –s /usr/local/lib/libtcmalloc_minimal.so.0.0.0/usr/local/lib/libtcmalloc.so
发动程序之前,预先加载tcmalloc动态库的环境变量设置:
# exportLD_PRELOAD=”/usr/local/lib/libtcmalloc.so
运用losf查看程序是否现已加载tcmalloc库:
# lsof -n | greptcmalloc
在Linux下运用的tcmalloc装置完结,在Windows下运用VS(2003以上版别)翻开工程项目gperftools.sln进行编译。

运用

将libtcmalloc.so/libtcmalloc.a链接到程序中,或许设置LD_PRELOAD=libtcmalloc.so。这样就能够运用tcmalloc库中的函数替换掉操作体系的malloc、free、realloc、strdup内存办理函数。能够设置环境变量设置如下:
         TCMALLOC_DEBUG=<level>       调试等级,取值为1-2
         MALLOCSTATS=<level>                    设置显现内存运用状况等级,取值为1-2
         HEAPPROFILE=<pre>                     指定内存走漏查看的数据导出文件
         HEAPCHECK=<type>                        堆查看类型,type=normal/strict/draconian
TcMalloc库还能够进行内存走漏的查看,运用这个功用有两种办法:
1)将tcmalloc库链接到程序中,留意应该将tcmalloc库终究链接到程序中;
2)设置LD_PRELOAD=”libtcmalloc.so”/HEAPCHECK=normal,这样就不需从头编译程序
翻开查看功用,有两种办法能够敞开走漏查看功用:
1)  运用环境变量,对整个程序进行查看: HEAPCHECK=normal /bin/ls
2)  在源代码中刺进查看点,这样能够操控只查看程序的某些部分,代码如下:
HeapProfileLeakCheckerchecker("foo");        // 开端查看
Foo();                                                                         // 需求查看的部分
assert(checker.NoLeaks());                                 // 完毕查看
调用checker树立一个内存快照,在调用checker.NoLeaks树立另一个快照,然后进行比较,假如内存有增加或许恣意改变,NoLeaks函数回来false,并输出一个信息告知你怎样运用pprof东西来剖析具体的内存走漏。
    履行内存查看:
         #LD_PRELOAD=libtcmalloc.so HEAPCHECK=strict HEAPPROFILE=memtm ./a.out
履行完结后会输出查看的成果,假如有走漏,pprof会输出走漏多少个字节,有多少次分配,也会输出具体的列表指出在什么当地分配和分配多少次。
         比较两个快照:
         #pprof --base=profile.0001.heap 程序名 profile.0002.heap
    已知内存走漏时,封闭内存走漏查看的代码:
void *mark =HeapLeakChecker::GetDisableChecksStart();
<leaky code>           //不做走漏查看的部分
HeapLeakChecker::DisableChecksToHereFrom(mark);
         注:在某些libc中程序或许要封闭查看才干正常作业。
         注:不能查看数组删去的内存走漏,比方:char *str = new char[100]; delete str;。


=================================装置短少库============================

libunwind库为依据64位CPU和操作体系的程序供给了根本的仓库曲折开解功用,其间包含用于输出仓库盯梢的API、用于以编程办法曲折开解仓库的API以及支撑12bet反常处理机制的API。

64位操作体系一定要先装libunwind这个库。

wget http://download.savannah.gnu.org/releases/libunwind/libunwind-1.1.tar.gz

tar zxvf libunwind-1.1.tar.gz
cd libunwind-1.1
CFLAGS=-fPIC ./configure
make CFLAGS=-fPIC
make CFLAGS=-fPIC install
posted @ 2018-08-24 11:22 长戟十三千 阅览(767) | 谈论 (0)修正 保藏
仅列出标题  下一页