How much free memory do you have

[MNTNBKR]

is there a way to check free mem without installing anything?

why are people so bent on having free ram? you do realize ram is pointless if nothing is in it right? you actually want your ram to be almost full all the time...

I don't quite understand the logic in this, but I'm willing to listen to an argument that supports it.

Anyway, I only look at my free mem (using ATK) when I start to experience lag. When that happens, it's always at or below 35MB. I hit Kill, and it usually jumps to 70MB or more and the lagging stops completely. I'm not sure why, because from what I understand it shouldn't be that way, but alas, it is for me. I chalk it up to beta apps running.

it's easier and faster for the OS to access RAM than it is anything else. try reading this link: Coding Horror: Why Does Vista Use All My Memory?

LOL...that's way too much reading to do with an almost 1 year old on my lap, so I'll take your word for it.

It just seems logical that if memory is full, then the OS has to start swapping old tasks for new in mem and thus using more processor time. Admittedly though, I could be WAY off base.

 

[bbohannon]

I'm with you. People on here always complain about people using task killers but honestly when my phone starts to lag and I kill everything, it always seems to run faster. Call me crazy, but it runs faster 9 times out of 10

 

[brochaos]

well, you don't want it to be 100% full, but close. i think we are on the same page. for example, windows vista/7 basically takes educated guesses at what you open the most, and has it preloaded.

but yeah, when it does have to swap, thats gonnag create a lag, but that is what we are trying to avoid by having the most common apps always loaded in memory.

I don't quite understand the logic in this, but I'm willing to listen to an argument that supports it.

Anyway, I only look at my free mem (using ATK) when I start to experience lag. When that happens, it's always at or below 35MB. I hit Kill, and it usually jumps to 70MB or more and the lagging stops completely. I'm not sure why, because from what I understand it shouldn't be that way, but alas, it is for me. I chalk it up to beta apps running.

it's easier and faster for the OS to access RAM than it is anything else. try reading this link: Coding Horror: Why Does Vista Use All My Memory?

LOL...that's way too much reading to do with an almost 1 year old on my lap, so I'll take your word for it.

It just seems logical that if memory is full, then the OS has to start swapping old tasks for new in mem and thus using more processor time. Admittedly though, I could be WAY off base.

 

[SSHGuru]

Mine is 14.83 gb total, 3.54 available (not a concern - I have 6 movies on the phone)

Internal - 26.48mb (where is the other 225k ram going?)

Do you mean>settings>SD card & phone storage?

Mine is:
SDcard
Total space: 14.93GB
Available space: 13.84GB

Internal phone storage:
Available space:
154MB

 

[Beta]

I'm brand new, but I'm going to do this anyway. A lot of you are confusing internal storage space and RAM. Internal storage space is like the hard drive on your computer and has nothing to do with RAM.

To view RAM usage go to Applications in your settings then running services. There's a multi colored bar at the bottom that shows what RAM you have free and used. Going to SD card & phone storage settings doesn't tell you anything about RAM.

SD Card: Total 14.87GB/Available 14.49GB
Internal: Available space 6.16GB...that's on an 8GB flash chip

These two places are where you store apps, photos, music, contacts, etc, etc, etc.

My RAM on the other hand reads: Other:121MB in 13 and Avail: 22MB+120MB in 24. Do I know what this means? No. My question is where is the other 249MB accounted for being the X has 512MB of RAM?

 

[BayouFlyFisher]

To keep your phone from lagging or slowing down, reboot it every day or so.

Here's a good article about how Android manages ram and why you should ignore it and about task killers:

How Android Manages Processes

In Android, processes and Applications are two different things. An app can stay "running" in the background without any processes eating up your phone's resources. Android keeps the app in its memory so it launches more quickly and returns to its prior state. When your phone runs out of memory, Android will automatically start killing tasks on its own, starting with ones that you haven't used in awhile.
The problem is that Android uses RAM differently than, say, Windows. On Android, having your RAM nearly full is a good thing. It means that when you relaunch an app you've previously opened, the app launches quickly and returns to its previous state. So while Android actually uses RAM efficiently, most users see that their RAM is full and assume that's what's slowing down their phone. In reality, your CPU—which is only used by apps that are actually active—is almost always the bottleneck.

Why Task Killers Are (Usually) Bad News

Apps like Advanced Task Killer, the most popular task killer in the Market, act on the incorrect assumption that freeing up memory on an Android device is a good thing. When launched, it presents you with a list of "running" apps and the option to kill as many as you want. You can also hit the Menu button to access a more detailed "Services" view, that lists exactly which parts of each application are "running", how much memory they take up, and how much free memory is available on your phone. This set-up implies that the goal of killing these apps is to free up memory. Nowhere on the list does it mention the number of CPU cycles each app is consuming, only the memory you'll free by killing it. As we've learned, full memory is not a bad thing—we want to watch out for the CPU, the resource that actually slows down your phone and drains your battery life.
Thus, killing all but the essential apps (or telling Android to kill apps more aggressively with the "autokill" feature) is generally unnecessary. Furthermore, it's actually possible that this will worsen your phone's performance and battery life. Whether you're manually killing apps all the time or telling the task killer to aggressively remove apps from your memory, you're actually using CPU cycles when you otherwise wouldn't—killing apps that aren't doing anything in the first place.
In fact, some of the processes related to those apps will actually start right back up, further draining your CPU. If they don't, killing those processes can cause other sorts of problems—alarms don't go off, you don't receive text messages, or other related apps may force close without warning. All in all, you're usually better off letting your phone work as intended—especially if you're more of a casual user. In these instances, a task killer causes more problems than it solves.
What You Should Do Instead

That said, not all apps are created equal. Many of you have used task killers in the past and actually found that after freeing up memory, your phone works a bit better. It's more likely that this is because you've killed a bad app—one that was poorly coded, and (for example) keeps trying to connect to the internet even when it shouldn't. Any performance increase you experience is more likely because you killed the right app, not because you freed up loads of memory (or, in many cases, it's just placebo). Instead of killing all those apps, find out which ones are actually causing the problems. If you really know what you're doing, you may benefit from using a task killer to stop the one or two inefficient-but-loved apps on your phone.
Note, however, that this is still a contested notion. A lot of developers (including ROM builder extraordinaire, Cyanogen) will not even look at your bug reports if you're using a task killer. In this humble blogger's opinion, your best bet is to stay away from regular task killer usage entirely. If you absolutely have to have that one battery-killing app on your phone, though, kill away—just be aware that when you experience a recurring Android bug later on, the task killer may be at fault. Of course, you can just stop using it to determine whether that is or isn't the case.