存档
圣斗士星矢的状态模式和观察者模式
[转贴] 游戏服务器架构二
来自:http://www.libing.net.cn/read.php/1724.htm
服务器公共组件实现 — 环形缓冲区
消息队列锁调用太频繁的问题算是解决了,另一个让人有些苦恼的大概是这太多的内存分配和释放操作了。频繁的内存分配不但增加了系统开销,更使得 内存碎片不断增多,非常不利于我们的服务器长期稳定运行。也许我们可以使用内存池,比如SGI STL中附带的小内存分配器。但是对于这种按照严格的先进先出顺序处理的,块大小并不算小的,而且块大小也并不统一的内存分配情况来说,更多使用的是一种 叫做环形缓冲区的方案,mangos的网络代码中也有这么一个东西,其原理也是比较简单的。
使用Jakarta Commons Pool处理对象池化
遭遇OutOfMemoryError
这几天,网店系统基础架构进行了一次大的升级,升级之后例行的进行了压力测试,以前几次大的项目发布压力测试都没有任何问题,没想到这次出事故啦,而且是内存泄露?
系统运行环境:
硬件:Intel(R) Xeon(R) CPU 2.0G、4G RAM、Linux 2.6.9-42.ELsmp #1 SMP
软件:jboss-4.0.5.GA [Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode)]
JAVA运行参数-server -Xms2048m -Xmx2048m -XX:NewSize=768m -XX:PermSize=128m -XX:MaxPermSize=128m
log4j配置文件基本含义说明
-
log4j.properties配置文件讲解如下:# Set root logger level to DEBUG and its only appender to A1
#log4j中有五级logger
#FATAL 0
#ERROR 3
#WARN 4
#INFO 6
#DEBUG 7配置根Logger,其语法为:
#log4j.rootLogger = [ level ] , appenderName, appenderName, …
log4j.rootLogger=INFO, A1 ,R
#这一句设置以为着所有的log都输出
#如果为log4j.rootLogger=WARN, 则意味着只有WARN,ERROR,FATAL
#被输出,DEBUG,INFO将被屏蔽掉.
# A1 is set to be a ConsoleAppender.
#log4j中Appender有几层如控制台、文件、GUI组件、甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等
#ConsoleAppender输出到控制台
log4j.appender.A1=org.apache.log4j.ConsoleAppender
# A1 使用的输出布局,其中log4j提供4种布局. org.apache.log4j.HTMLLayout(以HTML表格形式布局)
#org.apache.log4j.PatternLayout(可以灵活地指定布局模式),
#org.apache.log4j.SimpleLayout(包含日志信息的级别和信息字符串),
#org.apache.log4j.TTCCLayout(包含日志产生的时间、线程、类别等等信息)
C3P0 配置
官方文档 : http://www.mchange.com/projects/c3p0/index.html
<c3p0-config>
<default-config>
<!–当连接池中的连接耗尽的时候c3p0一次同时获取的连接数。Default: 3 –>
<property name=”acquireIncrement”>3</property>
阅读全文…ehcache 缓存设置策略
- <ehcache xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
- xsi:noNamespaceSchemaLocation=”ehcache.xsd”>
- <diskStore path=”java.io.tmpdir”/>
- <defaultCache
- maxElementsInMemory=”10000″
- maxElementsOnDisk=”0″
- eternal=”true”
- overflowToDisk=”true”
- diskPersistent=”false”
- timeToIdleSeconds=”0″
- timeToLiveSeconds=”0″
- diskSpoolBufferSizeMB=”50″
- diskExpiryThreadIntervalSeconds=”120″
- memoryStoreEvictionPolicy=”LFU”
- />
- <cache name=”demoCache”
- maxElementsInMemory=”100″
- maxElementsOnDisk=”0″
- eternal=”false”
- overflowToDisk=”false”
- diskPersistent=”false”
- timeToIdleSeconds=”119″
- timeToLiveSeconds=”119″
- diskSpoolBufferSizeMB=”50″
- diskExpiryThreadIntervalSeconds=”120″
- memoryStoreEvictionPolicy=”FIFO”
- />
- </ehcache>
- name:Cache的名称,必须是唯一的(ehcache会把这个cache放到HashMap里)。
maxElementsInMemory:内存中保持的对象数量。
maxElementsOnDisk:DiskStore中保持的对象数量,默认值为0,表示不限制。
eternal:是否是永恒数据,如果是,则它的超时设置会被忽略。
overflowToDisk:如果内存中数据超过内存限制,是否要缓存到磁盘上。
timeToIdleSeconds:对象空闲时间,指对象在多长时间没有被访问就会失效。只对eternal为false的有效。默认值0,表示一直可以访问。
timeToLiveSeconds:对象存活时间,指对象从创建到失效所需要的时间。只对eternal为false的有效。默认值0,表示一直可以访问。
diskPersistent:是否在磁盘上持久化。指重启jvm后,数据是否有效。默认为false。
diskExpiryThreadIntervalSeconds:对象检测线程运行时间间隔。标识对象状态的线程多长时间运行一次。
diskSpoolBufferSizeMB:DiskStore使用的磁盘大小,默认值30MB。每个cache使用各自的DiskStore。
memoryStoreEvictionPolicy:如果内存中数据超过内存限制,向磁盘缓存时的策略。默认值LRU,可选FIFO、LFU。
DES SecretKeyFactory not available 解决方法
mina read方法出现BufferUnderflowException异常的解决办法
现象:
先连续发几十个很小很小的包(<10 byte)
再突然发一个大小64byte的包
这时你会发现mina就会出现以下错误
java.nio.BufferUnderflowException
at java.nio.HeapByteBuffer.get(Unknown Source)
at org.apache.mina.core.buffer.AbstractIoBuffer.get(AbstractIoBuffer.java:419)
at org.apache.mina.core.buffer.AbstractIoBuffer.get(AbstractIoBuffer.java:827)
at com.labox.common.net.ProtocolHandler.messageReceived(ProtocolHandler.java:81)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:752)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:414)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$5(DefaultIoFilterChain.java:411)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:832)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$HeadFilter.messageReceived(DefaultIoFilterChain.java:616)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:414)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:408)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:582)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:542)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:534)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$7(AbstractPollingIoProcessor.java:532)
at org.apache.mina.core.polling.AbstractPollingIoProcessor$Worker.run(AbstractPollingIoProcessor.java:861)
最近评论