40/sec 对500/sec
介绍
由标题惊奇? 很好, 这是游览怎样我们崩裂了可测量性jinx 从处理贫乏40 个纪录每秒对500 个纪录每秒。当心, 我们面对的大多问题直接是向前, 因此有经验的人民也许发现这过剩。
内容
* 1.0 是我们?
1.1 记忆击中天空
1.2 低处理率
1.3 数据损失:- (
1.4 Mysql 拉下我们
1.5 缓慢的网络客户
* 2.0 向涅磐的路
2.1 控制记忆!
2.2 简化处理率
2.3 什么数据损失uh-uh?
2.4 定调的SQL 询问
2.5 定调的数据库图解
2.5 Mysql 帮助我们稳步前进!
2.6 快速地... 快速地网络客户
* 3.0 底线
我们在哪里是?
最初地我们有能称只40 个纪录/sec 的一个系统。我能甚而回忆讨论, 关于"什么应该是纪录的理想的率? "。最后我们决定, 40/sec 是理想的率为一个唯一防火墙。如此当我们必须出去, 我们atleast 需要支持3 个防火墙。因此我们决定, 120/sec 会是理想的率。根据数据从我们的competitor(s) 我们走向, 他们能支持在240/sec 附近的结论。我们认为它是好! 照原样我们的第一发行。由于所有竞争者谈论了防火墙的数量他支持了但不是在率。
记忆击中天空
我们的记忆总击中天空在512MB! (OutOfMemory 例外) 我们责备了我们不能逃脱为长期的cewolf(s) inmemory 贮藏引起的images.But! 不论是否我们联络了客户或不是我们过去经常击中天空在两三几天最大3-4 天平! 有趣的是, 这是可再生的当我们送了数据在非常高rates(then), 在50/sec 附近。您猜测它权利, 增长的无限的缓冲直到它击中屋顶。
低处理率
我们处理纪录以40/sec 的率。我们使用dataobject(s) 大块更新。但它没有给期望的速度! 因此我们开始囤积居奇数据在记忆造成囤积居奇记忆!
数据损失:- (
我们在很高速过去常错过许多packet(s) 。我们似乎有一点数据损失, 但那导致记忆肉猪。在一些扭捏限制缓冲区大小我们开始有平稳的数据损失大约20% 以非常高速率。
Mysql 拉下我们
我们面对困难时期当我们大约进口了140MB 记录文件。Mysql 开始hog, 机器开始的爬行并且有时它被停止的responding.Above 全部, 我们开始得到deadlock(s) 和交易timeout(s) 。哪些最终减少了系统的快速响应。
缓慢的网络客户
我们再这里责备了我们显示在页作为瓶颈图表的数量, 忽略事实有拉下系统的许多其它因素。页过去经常需要30 秒对装载为页与6-8 张图表和桌在4 天以后在互联网数据中心。
向涅磐的路
控制记忆!
我们设法投入极限在缓冲区大小的10,000, 但它没有持续长期。主要缺点在设计是, 我们假设, 缓冲大约10000 会满足, 即我们会是处理纪录在10,1000 伸手可及的距离缓冲之前。线型原则"某事可能去错误它将连同错误!" 它变错误。我们开始疏松数据。我们决定连同一展开文件基于的贮藏的Subsesquently, 数据被倾销了入展开文件, 会被装载入数据库使用"装载数据infile" 。这比大块插入物许多时间快速地是通过您也许并且想要对结算离开一些可能的优化以装载数据infile 的数据库司机。这解决了我们的增加未加工的纪录的缓冲区大小的问题。
我们面对的第二个问题是cewolf(s) 增量在记忆贮藏机制。它使用了"贮藏图象对象在记忆的TransientSessionStorage", 那里似乎是某一问题在清扫对象, 在rerferences 丢失了以后! 如此我们写了小"FileStorage" 实施存放图象对象在地方文件。并且会服务当请求时候进来。而且, 我们并且implmentated 清洁机制对清洁陈旧的images(图象旧比10mins) 。
我们发现的其它有趣的方面是这里, 垃圾收集工有低优先级因此对象被创造为各纪录, 几乎不被清扫了。这一点算术解释问题的巨大。每当我们接受我们创造~20 objects(hashmap 的一个日志纪录, tokenized 串等) 如此以500/sec 的率为1 秒, 对象的数量是10,000(20*500*1) 。由于重的处理垃圾收集工从未有一次机会对清洁对象。那么所有我们必须做是较小扭动, 我们分配了"零位" 到对象参考。Voila! 垃圾收集工是从未拷打我猜测; -)
简化处理率
处理率是在意味的贫乏40/sec 我们能几乎不承受甚而日志纪录的小爆发! 记忆控制给了我们某一solace, 但实际问题是以机敏的过滤器的应用在纪录。我们有大约20 物产为各个纪录, 我们曾经寻找所有物产。我们改变了实施到比赛为我们有标准为的那些物产! 而且, 我们并且有记忆泄漏在机敏过滤器处理。我们维护了永远增长的一个队列。如此我们必须维护一个展开文件对象倾销避免re 解析纪录形成对象! 而且, 我们过去常做寻找比赛行动为每个物产既使当我们没有安排机敏的标准被配置。
什么数据损失uh-uh?
一旦我们固定了记忆发布在接受数据即倾销入展开文件, 我们从未丢失了数据! 除那之外我们必须去除两三个不需要的索引在未加工的桌中避免天花板当倾销数据。我们hadd 索引为能有3 可能的价值最大值的专栏。哪些使插入物更慢和实际上不是有用的。
定调的SQL 询问
您的询问是您的钥匙对表现。一旦您开始钉牢问题, 您看见, 您也许甚而必须de 正常化桌。我们做了它! 这一些关键learnings:
* 用途"分析桌" 辨认怎么mysql 询问运作。这将给予您洞察力为什么询问是慢的, 即是否它使用正确索引, 是否它使用桌水平扫瞄等。
* 从未删除列当您应付巨大的数据按50,000 个纪录的顺序在一张唯一桌中。总尝试做"下落制表" 尽量。如果它不是可能的, 再设计您的图解, 是您唯一出口!
* 避免不需要的join(s), 不害怕de 正常化(即复制专栏价值) 避免join(s) 尽量, 他们倾向于拉下您的询问。一暗藏的好处是事实他们强加朴素在您的询问。
* 如果您应付大块数据, 用途"装载数据infile" 那里总是二个选择这里, 本机和遥控。使用本机如果mysql 和应用是在同样机器否则用途遥控。
* 设法分裂您的复杂询问成二次或三次更加简单的询问。好处在这种方法是, mysql 资源不hogged 为整个过程。倾向于使用临时表。而不是使用跨过横跨5-6 的一次唯一询问制表。
* 当您应付巨大的相当数量数据, 即您要对proces 对批量法说50,000 个纪录或更多在一次唯一询问尝试使用极限纪录。这将帮助您称系统对新高度
* 总使用更小的transaction(s) 代替大那些即跨过横跨"n" 桌。这把mysql 资源关起来, 也许导致系统迟钝为简单的询问
* 使用join(s) 在专栏以索引或外国钥匙
* 保证, 询问从用户界面有标准或限制。
* 并且保证, 标准专栏被标注
* 不要有数值在sql 标准在行情之内, 因为mysql 做型塑像
* 使用临时表尽量, 和投下它...
* select/delete 插入物是一把双重桌锁... 知道...
* 保重, 您不使mysql 数据库痛苦以您的更新频率对数据库。我们有我们过去常倾销对数据库在每300 个纪录之后的典型的案件。如此当我们开始测试对于500/sec 我们开始看见, mysql 逐字地拖我们下。那是我们意识到typicall 以500/sec 的率那里是"装载数据infile" 请求每秒钟对mysql 数据库。如此我们必须改变倾销纪录在3 分钟以后而不是300 个纪录。
定调的数据库图解
当您应付巨大的相当数量数据, 总保证, 您分成了您的数据。那是您的路对可测量性。一张唯一桌以言10 lakhs 可能从未称。当您打算执行询问为报告。总有桌、未加工的表一个为实际数据和其他集合的二个水平为报告tables(用户界面询问!) 的桌总保证, 关于您的报告桌的数据从未增长在极限之外。装箱您计划使用Oracle, 您能试验分成根据标准。但mysql 不幸地不支持那。如此我们将必须做那。维护里您通常有报头信息即制表寻找, 为一套指定的标准时间的阶桌在。
* 我们必须走通过我们的数据库图解并且我们补充说增加一些索引, 删除一些和平衡被复制的column(s) 取消昂贵的join(s) 。
* 去今后我们体会那有未加工的桌因为InnoDB 实际上是天花板对系统, 因此我们改变了它到MyISAM
* 我们并且去在程度减少上行数在静态桌里介入加入
* 零位在数据库桌里似乎导致某一表现击中, 因此避免他们
* 不要有索引为允许价值的2-3 的专栏
* 相互核对对各个索引的需要在您的桌里, 他们是昂贵的。如果桌是InnoDB 然后双检查他们的需要。由于InnoDB 桌似乎采取大约10-15 计时MyISAM 桌的大小。
* 使用MyISAM 每当有大多数, 或者(选择或插入物) 询问的当中一个。如果插入物和精选是然后最好有它作为InnoDB
Mysql 帮助我们稳步前进!
定调您的mysql 服务器在您优化您的queries/schemas 和您的代码之后。只您能然后看在表现的可感知的改善。这一些参量进来得心应手:
* 使用将使您的询问快速地执行的缓冲设备大小-- innodb_buffer_pool_size=64M 为InnoDB 和使用-- 钥匙bufer size=32M 为MyISAM
* 简单的询问开始花些更多时间比被期望。我们实际上困惑了! 我们意识到, mysql 似乎装载它开始插入任一张桌的索引。如此什么典型地发生了是, 任一次简单的询问对一张桌以5-10 列需要了大约1-2 秒。在进一步分析我们发现了在简单的询问之前, "装载数据infile" 发生。这消失了当我们改变了未加工的桌到MyISAM 类型, 因为缓冲区大小为innodb 和MyISAM 是二种不同配置。
为更加构形的参量看见这里。
要诀: 开始您的mysql 开始以以下选择-- 日志错误这将使能错误采伐
快速地... 快速地网络客户
用户界面是钥匙对任一个产品, 特别是页的被察觉的速度更加重要! 这也许进来得心应手解答和learnings 的名单:
* 如果您的数据不改变为言3-5 分钟, 最好贮藏您的客户端页
* 倾向于使用他们给被察觉的坚牢度您的页的Iframe(s)for 内在图表等。仍然改善用途Java 语言基于的美满的装货机制。这是某事您也许想要做当您有言3+ 图表在同样页。
* Internet Explorer 显示整体页只当所有内容被接受从服务器。如此它是适当使用iframes 或Java 语言为美满的装货。
* 从未使用CSS 文件的multiple/duplicate 词条在超文字标记语言页。Internet Explorer 倾向于装载各个CSS 文件作为一个分开的词条和申请在完全页!
最后结果您的询问和图解使系统更慢! 首先修理他们和然后责备数据库!
参见
* 高性能Mysql
* 询问表现
* 解释询问
* 优选询问
* InnoDB 定调
* 定调的Mysql
类别: 防火墙分析仪 | 表现打翻这页是最后更新18:00, 2005 年8月31 日。
- Ramesh-
文章来源: Messaggiamo.Com
Related:
» Seo Elite: New Seo Software!» AntiSpywareBOT
» Reverse Mobile
» Error Nuker
网管得到HTML代码
加上这条到你的网站！
网站管理员提交你的文章
无须登记！填写好的表格和你的文章是在 Messaggiamo.Com 目录！
