㈠ 7种检测python程序运行时间、CPU和内存占用的方法
1. 使用装饰器来衡量函数执行时间
有一个简单方法，那就是定义一个装饰器来测量函数的执行时间，并输出结果：
import time
from functoolsimport wraps
import random
def fn_timer(function):
@wraps(function)
def function_timer(*args, **kwargs):
t0= time.time()
result= function(*args, **kwargs)
t1= time.time()
print("Total time running %s: %s seconds" %
(function.__name__, str(t1- t0))
)
return result
return function_timer
@fn_timer
def random_sort(n):
return sorted([random.random() for i in range(n)])
if __name__== "__main__":
random_sort(2000000)
输出：Total time running random_sort: 0.6598007678985596 seconds
使用方式的话，就是在要监控的函数定义上面加上 @fn_timer 就行了
或者
# 可监控程序运行时间
import time
import random
def clock(func):
def wrapper(*args, **kwargs):
start_time= time.time()
result= func(*args, **kwargs)
end_time= time.time()
print("共耗时: %s秒" % round(end_time- start_time, 5))
return result
return wrapper
@clock
def random_sort(n):
return sorted([random.random() for i in range(n)])
if __name__== "__main__":
random_sort(2000000)
输出结果：共耗时: 0.65634秒
2. 使用timeit模块
另一种方法是使用timeit模块，用来计算平均时间消耗。
执行下面的脚本可以运行该模块。
这里的timing_functions是Python脚本文件名称。
在输出的末尾，可以看到以下结果：4 loops, best of 5: 2.08 sec per loop
这表示测试了4次，平均每次测试重复5次，最好的测试结果是2.08秒。
如果不指定测试或重复次数，默认值为10次测试，每次重复5次。
3. 使用Unix系统中的time命令
然而，装饰器和timeit都是基于Python的。在外部环境测试Python时，unix time实用工具就非常有用。
运行time实用工具：
输出结果为：
Total time running random_sort: 1.3931210041 seconds
real 1.49
user 1.40
sys 0.08
第一行来自预定义的装饰器，其他三行为：
real表示的是执行脚本的总时间
user表示的是执行脚本消耗的CPU时间。
sys表示的是执行内核函数消耗的时间。
注意：根据维基网络的定义，内核是一个计算机程序，用来管理软件的输入输出，并将其翻译成CPU和其他计算机中的电子设备能够执行的数据处理指令。
因此，Real执行时间和User+Sys执行时间的差就是消耗在输入/输出和系统执行其他任务时消耗的时间。
4. 使用cProfile模块
5. 使用line_profiler模块
6. 使用memory_profiler模块
7. 使用guppy包
㈡ Python如何进行内存管理
Python是如何进行内存管理的？
答:从三个方面来说,一对象的引用计数机制,二垃圾回收机制,三内存池机制。
一、对象的引用计数机制
Python内部使用引用计数，来保持追踪内存中的对象，所有对象都有引用计数。
引用计数增加的情况：
1，一个对象分配一个新名称
2，将其放入一个容器中（如列表、元组或字典）
引用计数减少的情况：
1，使用del语句对对象别名显示的销毁
2，引用超出作用域或被重新赋值
Sys.getrefcount( )函数可以获得对象的当前引用计数
多数情况下，引用计数比你猜测得要大得多。对于不可变数据（如数字和字符串），解释器会在程序的不同部分共享内存，以便节约内存。
相关推荐：《Python视频教程》
二、垃圾回收
1，当一个对象的引用计数归零时，它将被垃圾收集机制处理掉。
2，当两个对象a和b相互引用时，del语句可以减少a和b的引用计数，并销毁用于引用底层对象的名称。然而由于每个对象都包含一个对其他对象的应用，因此引用计数不会归零，对象也不会销毁。（从而导致内存泄露）。为解决这一问题，解释器会定期执行一个循环检测器，搜索不可访问对象的循环并删除它们。
三、内存池机制
Python提供了对内存的垃圾收集机制，但是它将不用的内存放到内存池而不是返回给操作系统。
1，Pymalloc机制。为了加速Python的执行效率，Python引入了一个内存池机制，用于管理对小块内存的申请和释放。
2，Python中所有小于256个字节的对象都使用pymalloc实现的分配器，而大的对象则使用系统的malloc。
3，对于Python对象，如整数，浮点数和List，都有其独立的私有内存池，对象间不共享他们的内存池。也就是说如果你分配又释放了大量的整数，用于缓存这些整数的内存就不能再分配给浮点数。
㈢ 退出python程序释放占用内存
一般情况下不会占内存，而且Python的内存需要的很小。如果用模拟器的话需要退出一下，输入close就可以了。请采纳，谢谢。
㈣ 使用 sys.getsizeof 查看 python 对象的内存占用
使用 sys.getsizeof 方法可以查看 python 对象的内存占用，单位：字节 (byte)
实际上是调用了 __sizeof__ 方法：
有些派唤数据类型告羡谈在 Python3 和 Python2 中占用的内存是不同的，例如 range ：
关于这个值是怎么算出来的，有待研究～
暂时已知：这个值包括该对象的数值、签名（包括数据类型、参数、调用方式等）等一系列数据所占总内存。可变对象所占内存可能极小，因为对象是袜碰指针，指向很大的数据。
㈤ python占内存大吗
你是问python的安装包嘛，如果是的话大概29M左右就够了，不怎么占内存。
㈥ python中flask如何降低内存
Dict
在小型程序中，特别是在脚本中，使用Python自带的dict来表示结构信息非常简单方便：
>>> ob = {'x':1, 'y':2, 'z':3}
>>> x = ob['x']
>>> ob['y'] = y
由于在Python 3.6中dict的实现采用了一组有序键，因此其结构更为紧凑，更深得人心。但是，让我们看看dict在内容中占用的空间大小：
>>> print(sys.getsizeof(ob))
240
如上所示，dict占用了大量内存，尤其是如果突然虚需要创建大量实例时：
实例数
对象大小
1 000 000
240 Mb
10 000 000
2.40 Gb
100 000 000
24 Gb
类实例
有些人希望将所有东西都封装到类中，他们更喜欢将结构定义为可以通过属性名访问的类：
class Point:
#
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
>>> ob = Point(1,2,3)
>>> x = ob.x
>>> ob.y = y
类实例的结构很有趣：
字段
大小(比特)
PyGC_Head
24
PyObject_HEAD
16
__weakref__
8
__dict__
8
合计：
56
在上表中，__weakref__是该列表的引用，称之为到该对象的弱引用(weak reference)；字段__dict__是该类的实例字典的引用，其中包含实例属性的值(注意在64-bit引用平台中占用8字节)。从Python3.3开始，所有类实例的字典的键都存储在共享空间中。这样就减少了内存中实例的大小：
>>> print(sys.getsizeof(ob), sys.getsizeof(ob.__dict__))
56 112
因此，大量类实例在内存中占用的空间少于常规字典(dict)：
实例数
大小
1 000 000
168 Mb
10 000 000
1.68 Gb
100 000 000
16.8 Gb
不难看出，由于实例的字典很大，所以实例依然占用了大量内存。
带有__slots__的类实例
为了大幅降低内存中类实例的大小，我们可以考虑干掉__dict__和__weakref__。为此，我们可以借助 __slots__：
class Point:
__slots__ = 'x', 'y', 'z'
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
>>> ob = Point(1,2,3)
>>> print(sys.getsizeof(ob))
64
如此一来，内存中的对象就明显变小了：
字段
大小(比特)
PyGC_Head
24
PyObject_HEAD
16
x
8
y
8
z
8
总计：
64
在类的定义中使用了__slots__以后，大量实例占据的内存就明显减少了：
实例数
大小
1 000 000
64 Mb
10 000 000
640 Mb
100 000 000
6.4 Gb
目前，这是降低类实例占用内存的主要方式。
这种方式减少内存的原理为：在内存中，对象的标题后面存储的是对象的引用(即属性值)，访问这些属性值可以使用类字典中的特殊描述符：
>>> pprint(Point.__dict__)
mappingproxy(
....................................
'x': ,
'y': ,
'z': })
为了自动化使用__slots__创建类的过程，你可以使用库namedlist(https://pypi.org/project/namedlist)。namedlist.namedlist函数可以创建带有__slots__的类：
>>> Point = namedlist('Point', ('x', 'y', 'z'))
还有一个包attrs(https://pypi.org/project/attrs)，无论使用或不使用__slots__都可以利用这个包自动创建类。
元组
Python还有一个自带的元组(tuple)类型，代表不可修改的数据结构。元组是固定的结构或记录，但它不包含字段名称。你可以利用字段索引访问元组的字段。在创建元组实例时，元组的字段会一次性关联到值对象：
>>> ob = (1,2,3)
>>> x = ob[0]
>>> ob[1] = y # ERROR
元组实例非常紧凑：
>>> print(sys.getsizeof(ob))
72
由于内存中的元组还包含字段数，因此需要占据内存的8个字节，多于带有__slots__的类：
字段
大小(字节)
PyGC_Head
24
PyObject_HEAD
16
ob_size
8
[0]
8
[1]
8
[2]
8
总计：
72
命名元组
由于元组的使用非常广泛，所以终有一天你需要通过名称访问元组。为了满足这种需求，你可以使用模块collections.namedtuple。
namedtuple函数可以自动生成这种类：
>>> Point = namedtuple('Point', ('x', 'y', 'z'))
如上代码创建了元组的子类，其中还定义了通过名称访问字段的描述符。对于上述示例，访问方式如下：
class Point(tuple):
#
@property
def _get_x(self):
return self[0]
@property
def _get_y(self):
return self[1]
@property
def _get_z(self):
return self[2]
#
def __new__(cls, x, y, z):
return tuple.__new__(cls, (x, y, z))
这种类所有的实例所占用的内存与元组完全相同。但大量的实例占用的内存也会稍稍多一些：
实例数
大小
1 000 000
72 Mb
10 000 000
720 Mb
100 000 000
7.2 Gb
记录类：不带循环GC的可变更命名元组
由于元组及其相应的命名元组类能够生成不可修改的对象，因此类似于ob.x的对象值不能再被赋予其他值，所以有时还需要可修改的命名元组。由于Python没有相当于元组且支持赋值的内置类型，因此人们想了许多办法。在这里我们讨论一下记录类(recordclass，https://pypi.org/project/recordclass)，它在StackoverFlow上广受好评(https://stackoverflow.com/questions/29290359/existence-of-mutable-named-tuple-in)。
此外，它还可以将对象占用的内存量减少到与元组对象差不多的水平。
recordclass包引入了类型recordclass.mutabletuple，它几乎等价于元组，但它支持赋值。它会创建几乎与namedtuple完全一致的子类，但支持给属性赋新值(而不需要创建新的实例)。recordclass函数与namedtuple函数类似，可以自动创建这些类：
>>>Point = recordclass('Point', ('x', 'y', 'z'))
>>>ob = Point(1, 2, 3)
类实例的结构也类似于tuple，但没有PyGC_Head：
字段
大小(字节)
PyObject_HEAD
16
ob_size
8
x
8
y
8
z
8
总计：
48
在默认情况下，recordclass函数会创建一个类，该类不参与垃圾回收机制。一般来说，namedtuple和recordclass都可以生成表示记录或简单数据结构(即非递归结构)的类。在Python中正确使用这二者不会造成循环引用。因此，recordclass生成的类实例默认情况下不包含PyGC_Head片段(这个片段是支持循环垃圾回收机制的必需字段，或者更准确地说，在创建类的PyTypeObject结构中，flags字段默认情况下不会设置Py_TPFLAGS_HAVE_GC标志)。
大量实例占用的内存量要小于带有__slots__的类实例：
实例数
大小
1 000 000
48 Mb10 000 000
480 Mb
100 000 000
4.8 Gb
dataobject
recordclass库提出的另一个解决方案的基本想法为：内存结构采用与带__slots__的类实例同样的结构，但不参与循环垃圾回收机制。这种类可以通过recordclass.make_dataclass函数生成：
>>> Point = make_dataclass('Point', ('x', 'y', 'z'))
这种方式创建的类默认会生成可修改的实例。
另一种方法是从recordclass.dataobject继承：
class Point(dataobject):
x:int
y:int
z:int
这种方法创建的类实例不会参与循环垃圾回收机制。内存中实例的结构与带有__slots__的类相同，但没有PyGC_Head：
字段
大小(字节)
PyObject_HEAD
16
ob_size
8
x
8
y
8
z
8
总计：
48
>>> ob = Point(1,2,3)
>>> print(sys.getsizeof(ob))
40
如果想访问字段，则需要使用特殊的描述符来表示从对象开头算起的偏移量，其位置位于类字典内：
mappingproxy({'__new__': ,
.......................................
'x': ,
'y': ,
'z': })
大量实例占用的内存量在CPython实现中是最小的：
实例数
大小
1 000 000
40 Mb
10 000 000
400 Mb
100 000 000
4.0 Gb
Cython
还有一个基于Cython(https://cython.org/)的方案。该方案的优点是字段可以使用C语言的原子类型。访问字段的描述符可以通过纯Python创建。例如：
cdef class Python:
cdef public int x, y, z
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
本例中实例占用的内存更小：
>>> ob = Point(1,2,3)
>>> print(sys.getsizeof(ob))
32
内存结构如下：
字段
大小(字节)
㈦ Python 多进程内存占用问题
当我们有一个很长很长的任务队列(mission_list)和阈值对应的一个处理函数(missionFunction)时，我们一般采用如下的方式进行处理：
但是，如果这任务列表很长很长，处理函数很复杂(占用cpu)时，单核往往需要很长的时间进行处理，此时，Multiprocess便可以极大的提高我们程序的运行速度，州粗相关内容请借鉴 multiprocessing --- 基于进程的并行 — Python 3.10.4 文档。
以上这种场景下，推荐大家采用最简单的进程池+map的方法进行处理，标准的写法， chunksize要借鉴官方的说法，最好大一点 ：
但是！！！！ 如果我们的任务列表非常的长，这会导致多进程还没跑起来之前，内存已经撑爆了，任务自然没法完成，此时我们有几种办法进行优化：
进程的启动方法有三种，可参考官方文档：
[图片上传失败...(image-48cd3c-1650511153989)]
在linux环境下，使用forkserver可以节省很多的内存空间， 因为进携迹衡程启动的是一个服务，不会把主进程的数据全部复制
采用imap会极大的节省空间，它返回的是一个迭代器，也就是结果列表：
但注意，以上写法中，你写的结果迭代部分必须写在with下面。或者采用另一种写法：
还有最后一种，当你的mission list实在太大了，导致你在生成 mission list的时候已经把内存撑爆了，这个时候就得优化 mission_list了，如果你的mission_list是通过一个for循环生成的，你可以使用yield字段，将其封装为一个迭代器，传入进程池：
这样子，我们就封装好了mission_list，它是一个可迭代对象，在取数据的辩做时候才会将数据拉到内存
我在项目中结合了后两种方法，原本256G的内存都不够用，但在修改后内存只占用了不到10G。希望能够帮助到你
㈧ 如何释放Python占用的内存
1.充分利用内存
任何一种图像处理软件对内存的要求都很高，Photoshop也一样。如果你在使用Photoshop时，没有使用其它的一些大软件，这时你就可以将Photoshop占用内存资源的比例提高。方法是：进行Photoshop，选择菜单下File\Preference\Memory & Image Cache命令，将Used by Photoshop的比例提高到80%~90%即可。
2.指定虚拟内存
在处理Photoshop时，内存被用完是很正常的，到时会大大影响Photoshop处理图像的时间，哪将怎么解决呢？方法是：你可以用硬盘来作为内存来使用，也就是常说的虚拟内存。请选择菜单下“File\Preference\Plug-Ins & Scratch Disks”命令。在这里的Scratch Disks下，你可以在硬盘上指定四个驱动器来作为虚拟内存，软件默认的虚拟内存是在Windows\temp之下。当第一个虚拟内存被使用光之后，Photoshop会自动去使用第二个Scratch Dsik，这样就提高了执行速度。
3.释放内存与硬盘空间
在进行图像处理时，你所进行的所有操作将会记录在Photoshop的History（历史记录）工作板中。这些操作包括：复制到Clipboard（粘贴板）、Undo（恢复）、Pattern（填充物）、Histories（记录）等几种，选择菜单下“Edit\Purge”命令。
进行这些操作之后，Photoshop会将这些图像和数据保存在内存里，使用该命令后，即将这些被占用的内存空间释放出来（RAM：Oh! Freeden）这样就让Photoshop有更多的Resource（资源）可用，自然就提高了效率。但注意，如果这些操作占用的内存比较少时，就没有必要使用啦！
除此之外，在处理大型图片时，Photoshop会自动产生一些临时文件，一般都很大，如果你处理的是一个20MB大小的宣传画时，那么临时文件可能就是100~150MB。请在Windows\temp或在你设定虚拟内存的驱动器里，将产生的Photoshop临时文件*.tmp删除掉。
㈨ 如何释放Python占用的内存
在上文的优化中，对每500个用户，会进行一些计算并记录结果在磁盘文件中。原本以为这么做，这些结果就在磁盘文件中了，而不会再继续占用内存；但实际上，python的大坑就是Python不会自动清理这些内存。这是由其本身实现决定的。具体原因网上多有文章介绍，这里就不了。
本篇博客将贴一个笔者的实验脚本，用以说明Python确实存在这么一个不释放内存的现象，另外也提出一个解决方案，即：先del，再显式调用gc.collect(). 脚本和具体效果见下。
实验环境一：Win 7， Python 2.7
[python] view plain
from time import sleep, time
import gc
def mem(way=1):
print time()
for i in range(10000000):
if way == 1:
pass
else: # way 2, 3
del i
print time()
if way == 1 or way == 2:
pass
else: # way 3
gc.collect()
print time()
if __name__ == "__main__":
print "Test way 1: just pass"
mem(way=1)
sleep(20)
print "Test way 2: just del"
mem(way=2)
sleep(20)
print "Test way 3: del, and then gc.collect()"
mem(way=3)
sleep(20)
运行结果如下：
[plain] view plain
Test way 1: just pass
1426688589.47
1426688590.25
1426688590.25
Test way 2: just del
1426688610.25
1426688611.05
1426688611.05
Test way 3: del, and then gc.collect()
1426688631.05
1426688631.85
1426688631.95
对于way 1和way 2，结果是完全一样的，程序内存消耗峰值是326772KB，在sleep 20秒时，内存实时消耗是244820KB；
对于way 3，程序内存消耗峰值同上，但是sleep时内存实时消耗就只有6336KB了。
实验环境二： Ubuntu 14.10， Python 2.7.3
运行结果：
[plain] view plain
Test way 1: just pass
1426689577.46
1426689579.41
1426689579.41
Test way 2: just del
1426689599.43
1426689601.1
1426689601.1
Test way 3: del, and then gc.collect()
1426689621.12
1426689622.8
1426689623.11
[plain] view plain
ubuntu@my_machine:~$ ps -aux | grep test_mem
Warning: bad ps syntax, perhaps a bogus '-'? See
ubuntu 9122 10.0 6.0 270916 245564 pts/1 S+ 14:39 0:03 python test_mem.py
ubuntu 9134 0.0 0.0 8104 924 pts/2 S+ 14:40 0:00 grep --color=auto test_mem
ubuntu@my_machine:~$ ps -aux | grep test_mem
Warning: bad ps syntax, perhaps a bogus '-'? See
ubuntu 9122 10.0 6.0 270916 245564 pts/1 S+ 14:39 0:03 python test_mem.py
ubuntu 9134 0.0 0.0 8104 924 pts/2 S+ 14:40 0:00 grep --color=auto test_mem
ubuntu@my_machine:~$ ps -aux | grep test_mem
Warning: bad ps syntax, perhaps a bogus '-'? See
ubuntu 9122 11.6 0.1 30956 5608 pts/1 S+ 14:39 0:05 python test_mem.py
结论：
以上说明，当调用del时，其实Python并不会真正release内存，而是将其继续放在其内存池中；只有在显式调用gc.collect()时，才会真正release内存。
进一步：
其实回到上一篇博客的脚本中，也让其引入gc.collect()，然后写个监控脚本监测内存消耗情况：
[plain] view plain
while ((1)); do ps -aux | sort -n -k5,6 | grep my_script; free; sleep 5; done
结果发现：内存并不会在每500个用户一组执行完后恢复，而是一直持续消耗到仅存约70MB时，gc才好像起作用。本环境中，机器使用的是Cloud instance，总内存2G，可用内存约为1G，本脚本内存常用消耗是900M - 1G。换句话说，对于这个脚本来说，gc并没有立即起作用，而是在系统可用内存从1 - 1.2G下降到只剩70M左右时，gc才开始发挥作用。这点确实比较奇怪，不知道和该脚本是在Thread中使用的gc.collect()是否有关，或者是gc发挥作用原本就不是可控的。笔者尚未做相关实验，可能在下篇博客中继续探讨。
但是，可以肯定的是，若不使用gc.collect(), 原脚本将会将系统内存耗尽而被杀死。这一点从syslog中可以明显看出。