我如何衡量 Clojure 程序使用了多少内存?
我已经注意到,即使是小程序,也就是这样说
(println "Hello World")
Run Code Online (Sandbox Code Playgroud)
根据时间(GNU时间),ps 和其他类似的工具,可以消耗数十兆字节的RAM 。
是否有任何正确的方法来检测 Clojure 程序真正需要多少内存?
如何限制 Clojure 程序的内存使用量?是否可以说“占用不超过 1 MB”之类的内容?
我运行mprof run some-executable并生成了一个*.dat文件。
文件的每一列代表什么*.dat意思?
vikas@some-host$ cat mprofile_20150224012014.dat
CMDLINE python ../asl
MEM 0.332031 1424769614.8950
MEM 7.593750 1424769614.9954
MEM 8.816406 1424769615.0957
MEM 8.816406 1424769615.1960
Run Code Online (Sandbox Code Playgroud)
第一/第二/第三列代表什么?
[编辑]: 我也无法运行 mprof run --python。这是我收到的错误(导入错误)......看起来它无法获取配置的定义
(virtualenv)vikas@host:$ ./mprof run --python ../myfile.py
mprof:每0.1s采样一次内存
作为 Python 程序运行...
Traceback (most recent call last):
File "/usr/lib64/python2.6/runpy.py", line 122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib64/python2.6/runpy.py", line 34, in _run_code
exec code in run_globals
File "/home/vikask/memory_profiler-0.32/memory_profiler.py", line 853, in <module>
execfile(__file__, ns, ns)
File "../myfile.py", line …Run Code Online (Sandbox Code Playgroud) 在尝试为某些 C/C++ 函数微调 Python 绑定中的一些内存泄漏时,我遇到了一些与 Numpy 数组的垃圾收集有关的奇怪行为。
为了更好地解释这种行为,我创建了几个简化的案例。代码是使用 运行的memory_profiler,其输出紧随其后。当涉及到 NumPy 数组时,Python 的垃圾收集似乎没有按预期工作:
# File deallocate_ndarray.py
@profile
def ndarray_deletion():
import numpy as np
from gc import collect
buf = 'abcdefghijklmnopqrstuvwxyz' * 10000
arr = np.frombuffer(buf)
del arr
del buf
collect()
y = [i**2 for i in xrange(10000)]
del y
collect()
if __name__=='__main__':
ndarray_deletion()
Run Code Online (Sandbox Code Playgroud)
使用以下命令,我调用了memory_profiler:
python -m memory_profiler deallocate_ndarray.py
这是我得到的:
Filename: deallocate_ndarray.py
Line # Mem usage Increment Line Contents
================================================
5 10.379 MiB 0.000 MiB @profile
6 def …Run Code Online (Sandbox Code Playgroud) python garbage-collection memory-leaks memory-management memory-profiling
我试图测量GC我的应用程序中两点之间花费了多少时间。像这样的东西:
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
gcPerfCounter.NextValue();
// This is the part that I would like to measure
doStuff();
var timeSpentInGC = gcPerfCounter.NextValue();
Run Code Online (Sandbox Code Playgroud)
但是,我不确定这是使用该计数器的正确方法。在这篇文章:正确使用“% Time in GC”性能计数器中,答案说它应该像秒表一样使用,这就是我在操作之前调用 NextValue() 的原因。我不认为是这种情况,因为当我删除第一gcPerfCounter.NextValue()行时,它给了我相同的结果。
MSDN 文章介绍了“% Time in GC”性能计数器:
显示自上次垃圾收集周期以来执行垃圾收集所花费的时间百分比。 https://msdn.microsoft.com/en-us/library/w8f5kw2e(v=vs.110).aspx
这让我很困惑,因为我认为自从上次以来GC cycle我们在 . 中花费的时间为零GC。所以根据这个描述,这个值应该始终为零。
您能解释一下这个性能计数器在我的例子中的含义和正确使用吗?
.net c# garbage-collection performancecounter memory-profiling
我的python程序占用了比预期更多的内存或由内存分析工具返回.我需要一个策略来查找内存泄漏并修复它.
我在64位Linux机器上运行python3脚本.几乎所有代码都捆绑在一个对象中:
obj = MyObject(*myArguments)
result = obj.doSomething()
print(result)
Run Code Online (Sandbox Code Playgroud)
在创建过程中obj,程序会读取大小为ca.的文本文件.100MB.由于我以多种方式保存信息,我希望整个对象占用几个hundret MB内存.
实际上,用asizeof.asized(obj)包pympler测量它的大小会返回大约123MB.但是,top告诉我我的程序占用大约1GB的内存.
我知道方法中的局部变量会占用更多的RAM.但是,查看我的代码,我发现这些局部变量都不会那么大.我asizeof.asized再次使用双重检查.
我不担心脚本需要1GB的内存.但是,我并行执行了一些方法(在12个方面):
class MyObject()
def doSomething(arg):
# do something
def myParallelMethod(args)
with sharedmem.MapReduce() as pool:
result = pool.map(self.doSomething, args)
return result
Run Code Online (Sandbox Code Playgroud)
这使得总内存使用量变为8GB,即使我将所有大对象放在共享内存中:
self.myLargeNumPyArray = sharedmem.copy(self.myLargeNumPyArray)
Run Code Online (Sandbox Code Playgroud)
我向测试程序保证内存真的是共享的.
检查asizeof,我在每个子进程中获得了
asizeof.asized(self) 是1MB(即比"原始"对象小得多 - 可能是由于共享内存,不计算两倍)asizeof.asized(myOneAndOnlyBigLocalVariable) 是230MB.总而言之,我的程序应该占用不超过123MB + 12*230MB = 2.8GB << 8GB.那么,为什么程序需要这么多内存呢?
一种解释可能是当程序并行运行时,我的对象中存在一些被隐藏的部分(垃圾?).
有没有人知道找出内存泄漏的策略?我该怎么办呢?
我已阅读有关内存分析多个线程,例如剖析内存在Python 3,是否有工作存储器剖析了Python3, …
我试图为以下复制文件的原始 Haskell 代码生成堆内存配置文件:
import System.Environment
import System.IO
import qualified Data.ByteString as B
import qualified Data.ByteString.Lazy as LB
naiveCopy :: String -> String -> IO ()
naiveCopy from to = do
putStrLn $ "From: " ++ from
putStrLn $ "To: " ++ to
s <- B.readFile from
B.writeFile to s
main = do
args <- getArgs
mapM (\ x-> putStrLn x) args
naiveCopy (head args) ((head.tail) args)
Run Code Online (Sandbox Code Playgroud)
使用 ghc 8.0.1 构建代码的命令:
ghc -o t -rtsopts -prof -fprof-auto t.hs
Run Code Online (Sandbox Code Playgroud)
收集分析数据的命令:
./t +RTS …Run Code Online (Sandbox Code Playgroud) 我很长一段时间忽略了这个工具,因为它只是.NET。
根据 MSDN 的说法,该诊断工具适用于在 Visual Studio 2015 中以“调试”方式编译的本机代码。
我正在关注: https ://learn.microsoft.com/en-us/visualstudio/profiling/memory-usage
我在“诊断工具”窗口的“内存使用情况”选项卡下启用了“堆分析”。然后,我重建所有项目,确保每个项目的工具集都是“Visual Studio 2015”,并确保为每个 dll 或 exe 项目构建 PDB。当客户端连接到我的进程时,以及在向客户端发送数据之后,我在 main 处设置了一个断点。其间有数千个对 new 的调用。每次我点击“拍摄快照”。当我单击“拍摄快照”时,会出现一行,其中包含时间、分配和堆大小。后两者被归零。
如果我对我的一个单元测试执行相同的操作,它们就会被填写,我可以按照文档中的描述进行深入研究。
我应该寻找什么才能让它与我的主要项目一起工作?是否有某些链接设置?我构建静态库和动态库重要吗?有什么具体需要寻找的吗?
我一直在阅读有关如何分析我的火花簇的信息。注意:我正在使用 pyspark。
我已经能够集成 cProfiler 以获取驱动程序级别和每个 RDD 级别的时间指标。但 cProfile 只能帮助节省时间。
如何分析我的 Spark 应用程序(使用 py-spark 编写)的内存使用情况?
我有兴趣找到内存和时间瓶颈,以便我可以重新访问/重构该代码。
另外,有时当我将更改推送到生产时,会导致 OOM(在执行器处),并且我最终会被动地修复代码。我认为将它与一些内存分析器集成将帮助我在测试过程中检测到问题。
我试图理解为什么当我导入一个大约 16MB 的文件作为变量时 PowerShell 的内存膨胀这么多。我可以理解围绕该变量存在额外的内存结构,但我只是想了解它为什么那么高。这是我在下面所做的 - 只是任何人都可以运行的另一个脚本的精简片段。
笔记/问题
我的测试代码
Invoke-WebRequest -uri "http://s3.amazonaws.com/alexa-static/top-1m.csv.zip" -OutFile C:\top-1m.csv.zip
Expand-Archive -Path C:\top-1m.csv.zip -DestinationPath C:\top-1m.csv
$alexaTopMillion = Import-Csv -Path C:\top-1m.csv
Run Code Online (Sandbox Code Playgroud)
对任何回答这个问题的人:感谢您的时间并帮助我每天学习更多!
memory powershell memory-profiling pscustomobject import-csv
我需要对函数进行内存使用分析。我正在使用带有Python 3.8.10的jupyter笔记本,并且我已经成功安装了memory_profiler 0.60,没有错误。当我加载 memory_profiler 时,使用%load_ext memory_profiler,没有出现错误,但是当我尝试使用 mprun ( %mprun -f suma2 suma2(0.2,0.2)) 时,出现此错误:
ERROR: Could not find file /tmp/ipykernel_75919/1494889556.py
Run Code Online (Sandbox Code Playgroud)
memory-profiling ×10
python ×4
memory ×2
.net ×1
apache-spark ×1
bytestring ×1
c# ×1
c++ ×1
clojure ×1
haskell ×1
import-csv ×1
jupyter ×1
jvm ×1
memory-leaks ×1
native ×1
powershell ×1
profiling ×1
pyspark ×1
python-3.x ×1