Ⅰ 如何減少python內存的消耗
我覺得可能是因為你的py文件在第一次啟動後，已經編譯成pyc文件了，再次啟動的時候都是載入pyc，省去了編譯的階段，所以速度很快。你可以試著把程序目錄下的所有pyc或者你的代碼文件對應的pyc文件刪除，看看是不是可以和第一次載入速度相同
Ⅱ python小程序在伺服器上運行比普通電腦快嗎
看你伺服器的性能和伺服器繁忙不繁忙
import time
import numpy as np
a=np.arange(200000000)
start=time.clock()
b=a**2
stop=time.clock()
print "Elapsed time: %.3f s" % (stop-start)
上邊這段代碼，在WIN10的筆記本上，Elapsed time =0.3秒左右，而在一個非常貴的伺服器LINUX上運行，竟然耗時0.5秒左右。反復試驗了多次都是這樣！
大牛解釋一下為啥啊？
Ⅲ python占內存大嗎
你是問python的安裝包嘛，如果是的話大概29M左右就夠了，不怎麼占內存。
Ⅳ python 數據太大 內存不足怎麼辦
買內存條插上，或者不要一次把數據全都讀入內存。
除了這兩個辦法，沒別的辦法了。
Ⅳ 如何釋放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中可以明顯看出。
Ⅵ 退出python程序釋放佔用內存
一般情況下不會占內存，而且Python的內存需要的很小。如果用模擬器的話需要退出一下，輸入close就可以了。請採納，謝謝。
Ⅶ python為何會內存超限，應該怎麼改
分區表錯誤是硬碟的嚴重錯誤，不同錯誤的程度會造成不同的損失。如果是沒有活動分區標志，則計算機無法啟動。但從軟區或光區引導系統後可對硬碟讀寫，可通過fdisk重置活動分區進行修復。如果是某一分區類型錯誤，可造成某一分區的丟失。分區表的第四個位元組為分區類型值，正常的可引導的大於32mb的基本DOS分區值為06，而擴展的DOS分區值是05。如果把基本DOS分區類型改為05則無法啟動系統 ，並且不能讀寫其中的數據。如果把06改為DOS不識別的類型如efh，則DOS認為改分區不是 DOS分區，當然無法讀寫。很多人利用此類型值實現單個分區的加密技術，恢復原來的正確類型值即可使該分區恢復正常。分區表中還有其他數據用於紀錄分區的起始或終止地址。這些數據的損壞將造成該分區的混亂或丟失，一般無法進行手工恢復，唯一的方法是用備份的分區表數據重新寫回，或者從其他的相同類型的並且分區狀況相同的硬碟上獲取分區表數據，否則將導致其他的數據永久的丟失。在對主引導扇區進行操作時，可採用nu等工具軟體，操作非常的方便，可直接對硬碟主引導扇區進行讀寫或編輯。當然也可採用de
Ⅷ python如何讓程序一直運行且內存資源自動釋放
這當然是和代碼寫法有關，不貼出來就無法解決
Ⅸ 為什麼電腦內存很大，python跑程序時卻說memory resource exhauted
要破這個東西，要先破你的演算法。 先別說破這個詞了。 梳理你的演算法，避免三重循環， 避免大量使用字典的多次嵌套。 顯然你的數據量巨大。還用這么耗內存，耗CPU的演算法。只有演算法改良了才能解決這個問題。即使給你C語編程，你都能把內存用光了。...
Ⅹ python 哪些方法可申請大塊內存，讓進程不佔用其他內存，只佔用申請的內存
可以找找內存池相關的東西。分配一個大內存池。然後所有變數從內存池分配內存空間。