User Functions
Don't have an account yet? Sign up as a New User
Who's Online
Guest Users: 12
|
| View previous topic :: View next topic |
| Author |
Message |
mindkey808
partially protected
Joined: 09 Nov 2009
Posts: 8
|
 Posted: Tue Mar 16, 2010 12:28 am Post subject: about Using FinalCutServer's memory |
 |
|
hi. i have some question
We are currently using FinalCutServer(8GB memory).
We checked "Activity Monitor→System Memory" in the menu, and then we found that there was only 150MB of free memory left.
Is this normal? Or should we increase the memory?
Thanks for your reply.... |
|
| Back to top |
|
 |
mjsanders
Could work for Apple
Joined: 02 Nov 2005
Posts: 59
|
| Posted: Tue Mar 16, 2010 4:17 am Post subject: |
|
|
Memory usage is not so easy to qualify as 'good' or 'bad'
If your server has few MB marked as Free is not neccesary a bad thing, it could also be proof that the OS uses all hardware it can get.
It could also mean you are trying to run too many processes on one server, or it could indicate that one of the processes has a 'memory leak' (it uses much more RAM than it is supposed to do)
What is most important are the number of page-outs per second.
In general, these should be (near) to zero for the last few seconds, since the page-outs are the steps that slow down a computer.
(do not use the number in Activity Monitor, since that are the page-outs since last boot, which can be high)
Use vm_stat for this. This is an example on my MacBook:
| Code: | MBMaurits:~ maurits$ vm_stat 2
Mach Virtual Memory Statistics: (page size of 4096 bytes, cache hits 0%)
free active spec inactive wire faults copy 0fill reactive pageins pageout
367846 271732 44740 177461 187927 275569K 4802714 111895K 86438 262115 12005
367969 272730 44740 177462 186610 709 0 627 0 1 0
367576 273424 44737 177461 186464 2292 2 2531 0 0 0
367417 273490 44737 177461 186464 1686 98 562 0 0 0 |
The first line in the pageout colum is the number since boot, the rest is 0 (per 2 seconds) (as it should)
You should also check which process has the highest amount of 'real memory' . Is that also your most important process? Normally the kernel is among the top users of memory.
Read this article for more informatation: http://support.apple.com/kb/HT1342
and the help page of Bernard Baehr'sMemory Monitor that I copy here:
| Quote: | Mac OS X Memory Management
As the CPU Monitor application (Activity Monitor with Mac OS X 10.3 and later) displays the usage of the CPU over time, Memory Monitor displays the memory usage of a Mac OS X system. But to understand the graph that Memory Monitor draws in its Dock icon, you need some basic understanding of the memory management of Mac OS X. And because Mac OS X is based on Darwin, a Unix like operating systems, this is a little tutorial about Unix virtual memory management. Don't worry, the average Mac user won't need to know this, but the Mac power user will want to know it anyway. When you want to monitor the processes (applications and system task) currently running on your Mac, you utilize the Process Viewer application (Activity Monitor with Mac OS X 10.3 and later). The Unix counterpart of Process Viewer is the command line tool «top». And when you run «top» (simply by typing «top» in a Terminal window), you additionally see a header block that contains one line with information about memory, for example:
PhysMem: 50M wired, 194M active, 181M inactive, 425M used, 23M free
This information, looking very strange compared to the memory usage information in the «About this Macintosh» dialog box of Mac OS 9, is visualized by Memory Monitor. But what does it actually mean?
50 megabytes of physical memory are «wired in place». This is stuff that has to stay in real RAM and can't be sent to disk by the virtual memory manager. The size of wired memory is shown with the most bottom bar of Memory Monitors Dock icon.
194 megabytes of physical memory are in use by applications or system software, but can be swapped out to disk if necessary. This part of memory is called «active» and is shown in the second bottom bar of Memory Monitors Dock icon.
181 megabytes of physical memory have stuff in it, but it's stuff that isn't actually in use. Unix is «lazy» about cleaning up memory. It marks it «inactive» but doesn't bother cleaning it out until it's needed. In some cases, it can be «reactivated» into active use, for example, if it holds the code for an application that was quit recently and that is now relaunched. That makes the program start much quicker as you can try out at your own: the first start of an application takes longer than the second or third relaunch. The inactive portion of physical memory functions as a kind of dynamically growing or shrinking disk cache. Its size is shown in the third bottom bar of Memory Monitors Dock icon.
425 megabytes are the sum of the wired, active and inactive memory. The rest of physical memory is free. The example comes from a Mac with 448 MB of RAM, so we have 23 megabytes of free memory. These 23 megabytes contain nothing the system can reclaim for any purpose. The amount of free memory is shown in the topmost bar in the Dock icon of Memory Monitor.
This tells us that the example Mac is in pretty good shape at first glance. There's real RAM available to programs that need it. And there is a very large amount of inactive memory that can be reclaimed or used in place of free memory, discarding the «cached» content the systems knows about. And we can get even more detailed information from the «vm_stat» (virtual memory statistics) command line tool:
[cube:~] bb% vm_stat
Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free: 1412.
Pages active: 51879.
Pages inactive: 48646.
Pages wired down: 12751.
"Translation faults": 61836589.
Pages copy-on-write: 2947749.
Pages zero filled: 18373114.
Pages reactivated: 2144395.
Pageins: 504520.
Pageouts: 95093.
Object cache: 512547 hits of 2355002 lookups (21% hit rate)
What does all that mean? Rather than type it all out for you, here's how you can find out yourself: simply type «man vm_stat» in a Terminal window. The Unix «man» command shows you the manual page for a command, that is, the instructions. (To learn how to use «man», try «man man».)
But one term of the vm_stat output must be explained here: what is a «page of memory»? Unix breaks memory down into «pages». A page is the minimum unit of memory that can be moved around by the virtual memory manager. With Mac OS X, a page has the size of four kilobytes. And because pages are the smallest moveable unit of memory, the process of rolling out memory to the disk is called «page out», retrieving pages from the disk into physical memory is called «page in».
Another interesting way to use vm_stat is to have it display a running count, by specifying the number of seconds you want it to wait between displays:
[cube:~] bb% vm_stat 1
Mach Virtual Memory Statistics: (page size of 4096 bytes, cache hits 21%)
free active inac wire faults copy zerofill reactive pageins pageout
2537 51832 47518 12801 61816392 2947715 18369682 2144360 504233 95093
2537 51832 47518 12801 68 0 3 0 0 0
2537 51832 47518 12801 71 0 3 0 0 0
2537 51832 47518 12801 68 0 3 0 0 0
2537 51832 47518 12801 68 0 3 0 0 0
2537 51832 47518 12801 68 0 3 0 0 0
^C
In this case, it outputs a line every second. It was stopped it by typing Control-C, the «break» command. (In the Unix command line, Control-C works like Command-Period works in the Mac GUI: it cancels the current activity.)
With vm_stat, we can ignore the very first line of numbers for now. That first line is a summary over time. It's the rest of the lines that is interesting.
Notice the «pageins» and «pageout» columns. Those show how many memory pages are being paged in from disk and out to the disk every second. And exactly these two numbers are visualized by the two additional graphs drawn in Memory Monitors Dock icon. (As long as there is no paging, these graphs are horizontal lines at the top and bottom of the icon.) Optionally, the number of pageins and pageouts can be shown in the Dock icon, too.
Pageins occur for two reasons: A new program is being started and its code is being paged in from the program file on disk, or the already-running program is accessing memory that was shuffled out to disk to make room. Because Unix systems use pageins for initial program loading (so called «demand paging»), pageins are unavoidable and the pagein rate is no indicator for insufficient physical memory.
Pageouts occur when you're out of physical memory. Remember, when a program quits, its code remains in memory if there is room until that memory needs to be freed for other purposes or you run the program again. So, if the system is paging out, you're running short on real memory. A small number of pageouts is normal for a Unix system that's working hard. But when you notice permanent pageouts (and consequently permanent pageins) when running your typical set of applications, adding more physical memory to your Macintosh will increase the systems performance significantly.
You are in real trouble when you start seeing lots of pageouts and pageins every second. That means that you're running lots more stuff than you have RAM to accommodate, and you're «thrashing» the disk (listen to the noise it makes!) sending stuff to virtual memory. It is very hard to make a modern Unix system actually run out of memory in normal use. It usually happens when a program has a «memory leak» that perpetually consumes more memory without letting any go. Normally, people get tired of thrashing the disk and having the machine grind down to a slow crawl. But at that point, the system has not technically run out of memory. It just went past the point where virtual memory is useful.
This is a very short overview over Unix virtual memory management. In detail, things are much more complicate. But hopefully you got enough information to use Memory Monitor as a performance indicator for your Mac OS X system. Feel free to contact the author to ask questions; the e-mail address you find in the About box of Memory Monitor. |
|
|
| Back to top |
|
|
mindkey808
partially protected
Joined: 09 Nov 2009
Posts: 8
|
| Posted: Tue Mar 16, 2010 5:56 pm Post subject: |
|
|
| mjsanders, Thanks for you very kind reply... |
|
| Back to top |
|
|
jfw
fully protected
Joined: 07 Mar 2010
Posts: 10
|
| Posted: Mon Mar 22, 2010 8:44 pm Post subject: |
|
|
wow, in case mjsanders's response was TMI...
If you have a lot of assets or are transcoding proxies on that system, you probably are running out and do need to upgrade your memory.
8 GB is enough for Final Cut Server alone with up to 250,000 assets. Add another 8 GB for every additional 250K assets you have.
Then, if you are transcoding on that same system (via "This Computer" or with it acting as a Qmaster node), add another 8 GB. |
|
| Back to top |
|
|
KathyHartman
JBOD
Joined: 03 Aug 2012
Posts: 1
|
| Posted: Fri Aug 03, 2012 8:29 am Post subject: |
|
|
Thanks a lot!
it's very kind of you to post it! 
______________
sudoku game |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
Xsanity Forum
Forum Search
Forum Help
Log in to check messages
Xsanity Articles
