同时发在 http://wangxu.me/blog/p/648 ,请当事人们补充下我没记下来的东东,另外,不破坏 cache line 的写法是怎么写的来着?
本月版聚的规格最后是8人座谈 + 晚饭欢送 hzmangel (@hzmangel, @古月圣)同学南下,座谈比讲幻灯片更轻松了一点,不过,还是讨论了一些严肃问题,很多都是开发中的常见误解和误用。废话少说,一一列出,没列的出是我忘了,各位在场同学请补充。
当Coly(@colyli, @淘泊松)抛出这个问题的时候,我们已经猜到 read() 快了,毕竟我们相信他会说些颠覆理解的东西,而且李凯(@leekayak)童鞋表示,他也听朱延海(@2002年一本漫画闯天涯)说过此事。那么,我们来听听 Coly 的解释:
这 来自于李凯同学的一次提问,Coly同学断然否认了在这方面两者的不同,表示,自 kernel 0.9 以来,所有的分给用户的页全是初始化过的,没有用户数据的页一定会给0,这是一个安全问题,内核不会把不属于用户的内容给用户看的。而且,文件系统也是如 此,空洞文件在读取未初始化过的文件内容时,返回的也一定是0。
当然,对于用户应用来说,C库提供的 malloc() 有可能会复用内存,而不是每次都从内核取,所以,有可能有未初始化内容。
提到初始化的时候,Coly 愤愤不平地表示,有童鞋居然这样初始化内存区域:
sprintf(buf,"");
并 表示,这一操作的行为是未知、未定义的。我和Bergwolf(@oatgnep, @Bergwolf)、李凯现场测试了一下,在使用 -Wall 开关编译的时候,会报出 WARN,提示使用了空的格式字符串。这是 C 库标准未定义行为的情况,这样使用会导致不可预期的情况出现,为什么不直接给 buf[0] 赋值 '\0' 呢。
在场童鞋表 示,他们都不会这么写 sprintf(),hzmangel 童鞋表示,他会用 memset() 填 0,于是,又引出了 Coly 的话题。他表示,这样操作在正确性上没有问题,但是会破坏 Cache Line,这些 0 区域将来会被重新写入,是完全没有读意义的,如果他们冲掉了正在很热的被访问的 Cache 中的内容,对于那块内存的访问可能对运行时间有严重的影响。所以,如果一定要写入,最好能够告诉 CPU,默默地写入,不要干扰 L1 Cache,这样可能会让写入更慢,但如果同时有其他 VIP 读 Cache 的内容的话,会因此受益。(怎么干我忘了,谁告诉我哈)
同时,对磁盘的访问也是如此,某些操作不希望写入硬盘的Cache,防止影响读取告诉缓存的数据,这样的写操作可以利用 SCSI 的 FUA/DPO 标识,在新内核中,对于支持 FUA/DPO 的设备,Ext4的 journal 会使用这种方式写入,而非 barrier,从而提高性能。
Coly 同学还提到了在他们的新 Kernel 上,老应用遇到的新问题。其中之一是某应用抱怨 sleep 开销变大,追查下去,是有四个线程频繁地 nanosleep 10 微秒,导致抢锁造成的。
“关于 sleep 一次至少会消耗1-2毫秒的认识早已经过时了”
这 个问题来自于早期程序员们坚信,sleep会让出CPU,由于调度问题,会有至少1-2毫秒的消耗,于是,甚至会有人用 sleep(0)。但是,高精度计时器(HPET)的引入使得 sleep 的精度已经大幅提升了,你要10微秒,就会给你 10 微妙,于是,锁的时候的 spinlock 争抢变得异常激烈了……
这个故事告诉我们,那些没有明确承诺过的 feature,也会随着时间的推移,悄悄地消失,成为陷阱,要么避开不用,要么总是留意。
这也是一个新 kernel 带来的问题,hadoop 运维童鞋会观测到 iowait 比原来的老 kernel 高了 10% 以上,这个究竟是不是问题呢。Coly告诉我们,请看看运行时间——实际任务的运行时间会快 10%……这是为什么呢?
这 个,解释下 wait time 是怎么计算的:内核每次采样看每个 CPU 的状态,如果 CPU 上是 idle,而且有任务在等 IO,就标记为 wait,那么,假设有16个CPU,如果有8个任务,分到16个CPU上,一直等IO,就是 50%,而如果有10个任务,分到两个 CPU上,就是 12.5%。这说明了什么问题呢——wait 并不全面反映等 IO 的严重性,新 kernel 更倾向于均匀地把任务分到更多 CPU 上,于是看起来 wait 值就高了。
这涉及到一个更科学的数据观的问题——你更关注的应该是任务的执行时间和效率、throughput、qps,而不是 CPU 的 wait time。
另外,iowait 时间是从 idle 中分化出来的,某些老的监控程序会直接用 (100% - idle%)当成 CPU 占用率,在 iowait 独立出去之后,会显得占用率变高。
已经写了不少了,其他的不是我不想写,是想不起来了……请补充啊。
另 外,Coly 强烈感谢了马涛(@淘泊瑜)为首的淘宝内核组童鞋们(羡慕嫉妒恨地说,他们还有美女 kernel 程序员……),作为国内互联网公司内,并入主线的 kernel patch 量当之无愧的老大,他们也是我们版聚的很多话题的来源,linuxfb 也感谢你们。
--
Wang Xu
--
To post to this group, send email to linu...@googlegroups.com
website: http://linuxfb.net
twitter: http://twitter.com/linuxfb
IRC: #linux...@irc.freenode.net
slideshare: http://www.slideshare.net/linuxfb
--
To post to this group, send email to linu...@googlegroups.com
website: http://linuxfb.net
twitter: http://twitter.com/linuxfb
IRC: #linux...@irc.freenode.net
slideshare: http://www.slideshare.net/linuxfb
2012/3/27 levin <levi...@gmail.com>:
>>>> spinlock 争抢变得异常激烈了......
>>>>
>>>> 这个故事告诉我们,那些没有明确承诺过的 feature,也会随着时间的推移,悄悄地消失,成为陷阱,要么避开不用,要么总是留意。
>>>>
>>>> iowait% 大了,是否是开销就变大了
>>>>
>>>> 这也是一个新 kernel 带来的问题,hadoop 运维童鞋会观测到 iowait 比原来的老 kernel 高了 10%
>>>> 以上,这个究竟是不是问题呢。Coly告诉我们,请看看运行时间----实际任务的运行时间会快 10%......这是为什么呢?
>>>>
>>>> 这 个,解释下 wait time 是怎么计算的:内核每次采样看每个 CPU 的状态,如果 CPU 上是 idle,而且有任务在等
>>>> IO,就标记为 wait,那么,假设有16个CPU,如果有8个任务,分到16个CPU上,一直等IO,就是 50%,而如果有10个任务,分到两个
>>>> CPU上,就是 12.5%。这说明了什么问题呢----wait 并不全面反映等 IO 的严重性,新 kernel 更倾向于均匀地把任务分到更多 CPU
>>>> 上,于是看起来 wait 值就高了。
>>>>
>>>> 这涉及到一个更科学的数据观的问题----你更关注的应该是任务的执行时间和效率、throughput、qps,而不是 CPU 的 wait time。
>>>>
>>>> 另外,iowait 时间是从 idle 中分化出来的,某些老的监控程序会直接用 (100% - idle%)当成 CPU 占用率,在
>>>> iowait 独立出去之后,会显得占用率变高。
>>>>
>>>> 其他
>>>>
>>>> 已经写了不少了,其他的不是我不想写,是想不起来了......请补充啊。
>>>>
>>>> 另 外,Coly 强烈感谢了马涛(@淘泊瑜)为首的淘宝内核组童鞋们(羡慕嫉妒恨地说,他们还有美女 kernel
>>>> 程序员......),作为国内互联网公司内,并入主线的 kernel patch 量当之无愧的老大,他们也是我们版聚的很多话题的来源,linuxfb
--
To post to this group, send email to linu...@googlegroups.com
website: http://linuxfb.net
twitter: http://twitter.com/linuxfb
IRC: #linux...@irc.freenode.net
slideshare: http://www.slideshare.net/linuxfb
��ϲlevinͬѧ��Ϊ�ҵĵ�200�ŷ�˿������
2012/3/27 Leaf John <leaf...@gmail.com>
������@cardmastertwitter�ϻ���@leafjohn
ͬʱ���� http://wangxu.me/blog/p/648 ���뵱�����Dz�������û�������Ķ��������⣬���ƻ� cache line ��д������ôд�����ţ�
���°�۵Ĺ�������8����̸ + �?���� hzmangel ��@hzmangel, @����ʥ��ͬѧ���£���̸�Ƚ��õ�Ƭ��������һ�㣬������������һЩ�������⣬�ܶ�ǿ����еij����������á��ϻ���˵��һһ�г���û�еij������� �ˣ���λ�ڳ�ͬѧ�벹�䡣
mmap() �� read() �ĸ���
��Coly��@colyli, @�Բ��ɣ��׳���������ʱ�������Ѿ��µ� read() ���ˣ��Ͼ������������˵Щ�߸����Ķ������������@leekayak��ͯЬ��ʾ����Ҳ������ ����@2002��һ�����������ģ�˵����¡���ô������������ Coly �Ľ��ͣ�
- ��ҹ��ڡ�mmap()��������ʶ������ read() ����Ҫ�ڴ濽���ģ�
- ����Ӳ�������ķ�չ��ʹ���ڴ濽����ĵ�ʱ���Ѿ������ˣ�
- ����mmap()���Ŀ�������һ�� pagefault�����������ȶ����Ѿ�����ˣ����� pagefault �Ĵ����������ڱ���ǰ������ˣ�
- ���ң�mmap֮�����ж��������ᾭ��ϵͳ���ã��� LRU �Ƚ����ʹ�õ�ҳ��ʱ��ռ���ƣ�
- ���ǣ���ͨ������£��ų��֮���������2B����������read() ͨ����� mmap() ���ø�졣
mmap() �� brk() �Ƿ�������ڴ���0
�� �������ͬѧ��һ�����ʣ�Colyͬѧ��Ȼ���������ⷽ�����ߵIJ�ͬ����ʾ���� kernel 0.9 ���������еķָ��û���ҳȫ�dz�ʼ����ģ�û���û���ݵ�ҳһ�����0������һ����ȫ���⣬�ں˲���Ѳ������û������ݸ��û����ġ����ң��ļ�ϵͳҲ���� �ˣ��ն��ļ��ڶ�ȡδ��ʼ������ļ�����ʱ�����ص�Ҳһ����0��
��Ȼ�������û�Ӧ����˵��C���ṩ�� malloc() �п��ܻḴ���ڴ棬����ÿ�ζ����ں�ȡ�����ԣ��п�����δ��ʼ�����ݡ�
sprintf() ������
�ᵽ��ʼ����ʱ��Coly �߷߲�ƽ�ر�ʾ����ͯЬ��Ȼ�����ʼ���ڴ�����
sprintf(buf,"");�� ��ʾ����һ��������Ϊ��δ֪��δ����ġ��Һ�Bergwolf��@oatgnep, @Bergwolf������ֳ�������һ�£���ʹ�� -Wall ���ر����ʱ�ᱨ�� WARN����ʾʹ���˿յĸ�ʽ�ַ����� C ���δ������Ϊ�����������ʹ�ûᵼ�²���Ԥ�ڵ�������֣�Ϊʲô��ֱ�Ӹ� buf[0] ��ֵ '\0' �ء�
memset() ��ʼ���ڴ���ʲô���⣨�Լ�Ӳ�̵�FUA/DPO��
�ڳ�ͯЬ�� ʾ�����Ƕ�������ôд sprintf()��hzmangel ͯЬ��ʾ������� memset() �� 0�����ǣ�������� Coly �Ļ��⡣���ʾ�������������ȷ����û�����⣬���ǻ��ƻ� Cache Line����Щ 0 �������ᱻ����д�룬����ȫû�ж�����ģ�������dz�������ں��ȵı����ʵ� Cache �е����ݣ������ǿ��ڴ�ķ��ʿ��ܶ�����ʱ�������ص�Ӱ�졣���ԣ����һ��Ҫд�룬����ܹ����� CPU��ĬĬ��д�룬��Ҫ���� L1 Cache��������ܻ���д��������ͬʱ������ VIP �� Cache �����ݵĻ�����������档����ô�������ˣ�˭�����ҹ���
ͬʱ���Դ��̵ķ���Ҳ����ˣ�ijЩ������ϣ��д��Ӳ�̵�Cache����ֹ Ӱ���ȡ���������ݣ������д������������ SCSI �� FUA/DPO ��ʶ�������ں��У�����֧�� FUA/DPO ���豸��Ext4�� journal ��ʹ�����ַ�ʽд�룬��� barrier���Ӷ�������ܡ�
nanosleep() �Ŀ������� kernel ��Ϊʲô�����κ�Sleep��������˯1���룿��
Coly ͬѧ���ᵽ�������ǵ��� Kernel �ϣ���Ӧ�������������⡣����֮һ��ijӦ�ñ�Թ sleep ����������ȥ�������ĸ��߳�Ƶ���� nanosleep 10 �룬����������ɵġ�
������ sleep һ�����ٻ����1-2�������ʶ���Ѿ���ʱ�ˡ�
�� ���������������ڳ���Ա�Ǽ��ţ�sleep���ó�CPU�����ڵ������⣬��������1-2�� �����ģ����ǣ������������� sleep(0)�����ǣ��߾��ȼ�ʱ����HPET��������ʹ�� sleep �ľ����Ѿ���������ˣ���Ҫ10�룬�ͻ���� 10 ����ǣ����ʱ��� spinlock ��������쳣�����ˡ���
������¸������ǣ���Щû����ȷ��ŵ��� feature��Ҳ������ʱ������ƣ����ĵ���ʧ����Ϊ���壬Ҫô�ܿ����ã�Ҫô�������⡣
iowait% ���ˣ��Ƿ��ǿ���ͱ����
��Ҳ��һ���� kernel ���������⣬hadoop ��άͯЬ��۲ iowait ��ԭ������ kernel ���� 10% ���ϣ���������Dz��������ء�Coly�������ǣ��뿴������ʱ�䡪��ʵ�����������ʱ���� 10%��������Ϊʲô�أ�
�� ���������� wait time ����ô����ģ��ں�ÿ�β���ÿ�� CPU ��״̬����� CPU ���� idle�������������ڵ� IO���ͱ��Ϊ wait����ô��������16��CPU�������8�����ֵ�16��CPU�ϣ�һֱ��IO������ 50%���������10�����ֵ����� CPU�ϣ����� 12.5%����˵����ʲô�����ء���wait ����ȫ�淴ӳ�� IO �������ԣ��� kernel �������ھ��ȵذ�����ֵ���� CPU �ϣ����ǿ����� wait ֵ���ˡ�
���漰��һ�����ѧ����ݹ۵����⡪������ע��Ӧ���������ִ��ʱ���Ч�ʡ� throughput��qps������ CPU �� wait time��
���⣬iowait ʱ���Ǵ� idle �зֻ������ģ�ijЩ�ϵļ�س����ֱ���� ��100% - idle%������ CPU ռ���ʣ��� iowait ������ȥ֮���Ե�ռ���ʱ�ߡ�
����
�Ѿ�д�˲����ˣ�����IJ����Ҳ���д�����벻�����ˡ����벹�䰡��
�� �⣬Coly ǿ�Ҹ�л�����Σ�@�Բ�褣�Ϊ���Ա��ں���ͯЬ�ǣ���Ľ���ʺ�˵�����ǻ�����Ů kernel ����Ա����������Ϊ���ڻ�����˾�ڣ��������ߵ� kernel patch ����֮�������ϴ�����Ҳ�����ǰ�۵ĺܶ�����Դ��linuxfb Ҳ��л���ǡ�
--
Wang Xu
--
Wang Xu
--
To post to this group, send email to linu...@googlegroups.com
website: http://linuxfb.net
twitter: http://twitter.com/linuxfb
IRC: #linux...@irc.freenode.net
slideshare: http://www.slideshare.net/linuxfb
--
Best Reagres,
Leaf Johnson<leaf...@gmail.com>
Mobile Developer, Linux Fun, http://about.me/leaf
2012/3/27 levin li <levi...@gmail.com>:
> 来得早不如来得巧,话说你微博跟twitter对不上号,我都不知道你之前关注过我哈
微博上是@cardmastertwitter上还是@leafjohn
--
To post to this group, send email to linu...@googlegroups.com
website: http://linuxfb.net
twitter: http://twitter.com/linuxfb
IRC: #linux...@irc.freenode.net
slideshare: http://www.slideshare.net/linuxfb
--
Wang Xu
--
To post to this group, send email to linu...@googlegroups.com
website: http://linuxfb.net
twitter: http://twitter.com/linuxfb
IRC: #linux...@irc.freenode.net
slideshare: http://www.slideshare.net/linuxfb