㈠ 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中可以明顯看出。