和兄弟们聊内存的事

Android郎哲 11:26:28

10分钟左右

晕  11:26:36

你的数据库是什么?

Android郎哲 11:26:49

mysql

 

晕  11:27:14

报错说申请多少失败?

Android郎哲 11:27:23

另一种情况

用户在3 4 W 相互发消息时 失败

Android郎哲 11:27:27

LinkTalk 11:27:29

3.2G支持9万或许是少了点

晕  11:26:30

你内存里面都存放什么?

LinkTalk 11:26:48

在线9万时会导致什么现象?

Android郎哲 11:27:43

eheap_alloc: Cannot allocate

Android郎哲 11:28:06

eheap_alloc: Cannot allocate 62690240 bytes of memory (of type "heap").

晕  11:27:44

报错说申请多少内存失败?

 

LinkTalk 11:27:48

你这个是什么应用?或者跑的什么类型的业务?

Android郎哲 11:29:05

ejabberd

LinkTalk 11:29:20

erlang会有大量的内存复制操作,或许内存开销比较大

LinkTalk 11:29:34

我这里也有个10万左右长连接的,java的,我分配了7个G内存

Android郎哲 11:30:09

你内存那么大

Android郎哲 11:30:25

我4G内存 因为是32操作系统 很多用不了

LinkTalk 11:30:26

我机器16G内存,呵呵

LinkTalk 11:30:41

我是公司配的服务器,所以肯定比你好点

yan(402344512)  11:30:50

连接越多,内存消耗太大了

Android郎哲 11:30:53

哈哈

LinkTalk 11:30:59

这么多人在线,为什么用个pc机器?

LinkTalk 11:31:18

是线上的产品机,还是内部模拟测试的环境?

Android郎哲 11:31:21

我一直都是在PC机上上测试的

Android郎哲 11:31:29

内部模拟环境

yan(402344512)  11:31:30

如果每个连接处理的东西很多的话,会很慢的吧?

LinkTalk 11:31:33

那9万是如何模拟的?

LinkTalk 11:31:39

也是用erlang模拟长连接吗?

Android郎哲 11:31:52

tsung 模拟的 是长连接

LinkTalk 11:31:58

哦,了解

LinkTalk 11:32:08

那你每个连接存在多长时间?

LinkTalk 11:32:11

还是一直存在?

Android郎哲 11:32:15

一直存在

yan(402344512)  11:32:32

每个连接的处理数据量如何?

LinkTalk 11:32:39

哦,那不一样。真实环境中,长连接频繁的创建与释放

yan(402344512)  11:32:42

处理逻辑多不多?

LinkTalk 11:32:53

所以最好模拟一下创建与释放,更加符合实际线上环境

Android郎哲 11:32:55

还没处理逻辑

Android郎哲 11:33:02

只是连接上

LinkTalk 11:33:16

socket的创建与销毁其实开销要比长久保存大许多

yan(402344512)  11:33:19

那处理比较多的逻辑的话,那恐怕会很慢哦

LinkTalk 11:33:23

哦,了解

Android郎哲 11:33:46

处理逻辑的话 三四万就内存不足了

LinkTalk 11:34:06

那你9万的模拟连接的时候大概占多少cpu?

LinkTalk 11:34:15

嗯,是的,erlang大量的内存复杂

LinkTalk 11:34:19

内存复制

yan(402344512)  11:34:39

一个JVM,10W连接?

Android郎哲 11:34:53

CPU 80% 多

LinkTalk 11:34:55

嗯,以前是一个jvm

Android郎哲 11:34:59

双核

LinkTalk 11:35:09

现在我改成了7个jvm,每个1G

LinkTalk 11:35:20

多个jvm更加稳定

yan(402344512)  11:35:22

但那要是处理器逻辑, 一个JVM的反应速度会不会变得很慢了呢?

LinkTalk 11:35:54

不慢,一个jvm的时候大概站20%cpu,改成多个进程负载均衡之后,现在10%左右

LinkTalk 11:36:13

不过我机器比较好,两颗4核至强

Android郎哲 11:36:14

才 10% 这么低

yan(402344512)  11:36:17

相当于7个JVM做负载?

LinkTalk 11:36:17

LinkTalk 11:36:20

是的

yan(402344512)  11:36:22

当一个JVM使用?

Android郎哲 11:36:41

我双核 我怎么分配 合理使用CPU

Android郎哲 11:36:49

以前没做过

LinkTalk 11:37:42

erlang自动支持smp

yan(402344512)  11:37:47

jvm咋个搞均衡负载啊, 没弄过

LinkTalk 11:37:49

所以不用你考虑,呵呵

LinkTalk 11:38:02

其实现在绝大部分语言都自动利用多核cpu的

yan(402344512)  11:38:12

 

LinkTalk 11:38:17

线程调度分配到各个cpu核上,这个是操作系统做的事情

Android郎哲 11:38:26

对 

 

Android郎哲 11:38:27

Erlang R13B03 (erts-5.7.4) [source] [smp:2:2] 

LinkTalk 11:38:28

一些语言可以让你指定cpu affinity

yan(402344512)  11:38:41

java也行?

LinkTalk 11:38:58

erlang在smp方面一直做一些优化,所以在多核处理方面erlang会有少量优势

Android郎哲 11:39:07

java 是怎么指定的 复杂不

LinkTalk 11:39:13

不过erlang本身语言代码的执行效率并不高

LinkTalk 11:39:27

java我倒没有找过这方面的资料,C#可以

Android郎哲 11:39:34

LinkTalk 11:39:39

process有个processor affinity属性

LinkTalk 11:39:49

c/c++肯定可以

LinkTalk 11:40:02

这个一般用不到,最好让操作系统来调度

yan(402344512)  11:40:23

oc4j 来搞?

LinkTalk 11:41:38

郎哲,你用ejabberd做什么业务开发?

Android郎哲 11:41:44

兄弟们 针对我的问题 还有什么好的调试方法

LinkTalk 11:42:49

我觉得或许不是问题,是你要求太高了,erlang本身在高并发的时候就应该多分配内存才行

Android郎哲 11:43:43

  难道真的时候我要求高了?

我目前 没什么 可以做比较

KantSpionJohn(19868898)  11:44:36

R14B01好像也对smpw优化了。

KantSpionJohn(19868898)  11:44:39

smp

LinkTalk 11:44:59

嗯,我看erlang的很多次发布都提到smp优化,呵呵

T.t.  11:52:21

问个问题。linux 内存分为内核区和用户区。

用epoll发起一个socket的read请求。。

当数据就绪的时候,其实就是内核区已经接收到数据,然后通知用户进程将这个数据读取到用户区。。

 

那么这里有一个疑问。。是内核区一接收到数据就通知么?还是接收到一定量的时候才通知?

LinkTalk 11:53:38

我不清楚,但是我直觉觉得应该有一个缓存队列的机制

LinkTalk 11:54:01

不过从应用层的角度来看,你可以认为是基本实时的

T.t.  11:54:44

其实我就是想搞清楚。通知的条件是什么。

我倾向于收到到一定量的时候通知

LinkTalk 11:54:50

而且tcp是基于流的,你上层的应用程序本身也要缓存并组包

LinkTalk 11:55:10

这个我也不清楚,呵呵,你有兴趣和时间可以自己去看kernel的代码,哈哈

T.t.  11:55:17

呵呵

LinkTalk 11:59:43

做高并发软实时的系统的时候,内存一定要大,老外说过:memory is disk, disk is tape,呵呵

T.t.  12:00:41

 都用内存池嚒?

T.t.  12:00:51

先申请好内存再说

LinkTalk 12:01:04

现在内存越来越便宜


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值