如何分析程序的失控内存使用情况并更正潜在的错误 [英] How do I analyze my program's run-away memory usage and correct the underlying error

问题描述

帮助-我有一个相对较大的c/C ++混合项目(15个文件.c和.cpp)，我最近对其进行了修改.所做的修改使程序逐渐消耗了所有可用的内存.我暂时从最可疑的文件中删除了更改，问题仍然存在.该程序使用了大量的ODBC MySQL查询，但是对于释放语句句柄，关闭游标和连接非常干净.进程初始化中有一些malloc，但是它们只有一次，每次都有一个空闲时间.我已经使用各种工具(包括Virtual Leak Detector，Deleaker和crtdbg)检查了内存泄漏，它们都表示没有泄漏.因此，我正在研究其他类型的问题，例如意外递归或意外进入相邻例程.该程序即使消耗了所有可用内存也不会中止-事情变得非常缓慢.我正在寻找一个Windows工具(最好是免费的)，该工具将分析程序的私有工作集并确定各种内存块的来源.

Help - I have a relatively large mixed c/C++ project (15 files .c and .cpp) which I recently modified. The modifications caused the program to gradually consume all available memory. I have temporarily removed the changes from the most suspect files and the problem still persists. The program uses a lot of ODBC MySQL queries, but is very clean about freeing Statement Handles, closing cursors and Connections. There are some mallocs in process initialization but they are only one time and there is a free for each. I have checked for memory leaks with a variety of tools including Virtual Leak Detector, Deleaker and crtdbg and they have all indicated no leaks. So I am looking at some other kind of problem like unintended recursion or an unintended entry into adjacent routines. The program doesn''t abort even when it has consumed all available memory - things just become very slow.I am looking for a windows tool (preferably free) which will analyze the programs private working set and identify what the various memory blocks are from. Would really appreciate any help.

推荐答案

当资源用尽时，事情总是变慢，并且退出程序花很长时间，这没什么好研究的. br/>
有一个明显的问题，您确定是您的程序正在增长并消耗所有资源吗?我的意思是说SQL Server不是在同一台机器上，而是它正在膨胀以占用所有内存.

Things always become slow when you run out of resources and takes a long time to exit from the program that is nothing to investigate.

There is one obvious question are you sure it''s your program that is growing and consuming all the resources? By that I mean the SQL server isn''t on the same machine is it and it is bloating it''s cache up to consume all memory.

您需要首先确定问题所在.

为此，找到一些区域(这些区域是中央代码字段)并注释掉所有内容并运行代码是很有用的.如果确实可以解决问题，请逐步激活更多详细信息，然后找到问题所在的代码.

检查SQL Server的日志，以查找数据库连接代码中的一些错误.

您是否在某处列出或缓存了数据?

you need to identify the problems first.

For that it is useful to find some areas which are central code fields and comment ALL out and run the code. If that does solve the problem, activate step after step more details and you find the code which is the problem.

Check the Logs of the SQL-Server for finding some bugs in your database-connection code.

Have you lists or array with cached data somewhere?

对于静态代码分析，这里是工具列表:http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis [ ^ ]

但是，内存管理本身可能没有什么问题-可能仅仅是程序设计不正确，并且确实使用了那么多的内存.由于您显然具有数据库应用程序，因此首要原因应该很明显:将数据库中的数据保存在内存中！您应该检查所有读取数据的功能，并确保它们保留该数据的时间不会超过必要的时间.也许您还可以找到减少所需内存量的方法.

另一个潜在的问题是SQL连接:如果您不注意如何从连接表中读取数据，那么处理多个表的连接所需的内存量很容易爆炸！示例:即使从筛选器将记录集减少到几条，从人，地址，汽车，保险，银行账户中选择*"，如果所涉及的五个记录中只有100条记录，则初始选择联接5个表将创建一个具有100亿条记录的虚拟表！您应该通过使用将表一对一连接的子选择语句来避免这种情况.当然，这是非常假设的:一个好的数据库引擎可以识别并相应地进行优化-但根据您的sql语句的外观，您可能需要手动对其进行优化.

For static code analysis, here''s a list of tools: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis[^]

However, it may be that there is nothing wrong with your memory management per se - maybe it is just that your program isn''t well designed and really uses that much memory. Since you obviously have a database application, the prime reason should be obvious: holding data from your database in memory! You should check all functions that read data and make sure they don''t hold onto that data for longer than necessary. Maybe you can also find ways to reduce the required amount of memory.

Another potential problem is SQL joins: If you don''t pay attention on how you read data from joined tables, then the amount of memory required to process a join of multiple tables can easily explode! Example: "Select * from persons, addresses, cars, insurances, bankaccounts where ..." even if the filter reduces the set of records to just a few, if each of the five involved has only 100 records, then the initial select joining 5 tables creates a virtual table with 10 billion records! You should strive to avoid that by using sub select statements that join tables one on one. Of course, that is highly hypothetical: a good database engine may recognize that and optimize accordingly - but depending on how exactly your sql statements look, you may need to optimize them manually.

这篇关于如何分析程序的失控内存使用情况并更正潜在的错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！