Moving Host - concern about PHP memory limit I'm moving my projects from Bluehost to GreenGeeks, and I'm concerned about the Drupal (v7) PHP memory limits.  Maybe I'm overly concerned, but has anyone experienced any issues with GG or BH about running Drupal for clients' commercial projects requiring more than average PHP memory levels above 64meg to a max 128meg memory requirement. Any comments welcome.
A 128M memory limit is often not "more than average" for a Drupal project.
Also, just because you've specified 128M as the memory limit, that doesn't mean your webhost is giving you that much (or even half as much).

Let me explain.
I'll use Commerce Kickstart v2 with the demo store installed as an example (matching a medium-sized Commerce store).
It has 10 content types, 6 product types.
146 modules installed, out of that 23 provided by Drupal core, and 123 contrib.

Installing Commerce Kickstart requires 77M of RAM (xhprof peak memory usage).
A Kickstart page (frontpage, the view that lists products in a category, faceted search page) takes about 17M (as reported by devel).
This number can spike easily on admin pages that show many items, or thanks to a misbehaving module.

Our minimum memory limit requirement for Kickstart is 128M, based on our personal experience developing Drupal sites (it's easy to get "memory limit exceeded" with less than that). 
Also, if the server doesn't have enough memory when generating the request, it won't give you how much you asked for. I saw it with my own eyes (MacBook Pro, Chrome with a million tabs, only a bit of RAM left. PHP fails to allocate 77M of ram despite the memory limit being 128M).
I also saw this complaint from people with shared hosting (I strongly believe that running anything more than a blog on shared hosting is pure masochism without excuse in the age of cheap VPS).

Why does Drupal need so much memory? Among other things, because it has a cache problem (which of course saves your database)
Drupal currently likes to cache ALL views in one place, ALL fields in one place, etc. So once you get a site with many content types, fields, views, the caches become huge, and they are all loaded into your memory with each request.
Thankfully, this is being fixed as we speak, thanks to people like catch (See this article for details).

The fix to Views got committed a few days ago and is now available in 7.x-3.x-dev. Quoting #29 from that thread, where the memory usage for Views dropped from 34M to 17M:


  So, for normal use, there's a 15% improvement in execution time, and 49% improvement in memory usage.


There is also a RTBC fix for fields in Drupal core that should make it into the next Drupal 7 release. Benchmarks showed savings between 1M and 50M (depending on your number of fields).

There's an in-progress fix for the system (module &amp; theme) list in Drupal core that should shave a megabyte or two as well.

So, install Devel, go to admin/config/development/devel, enable "Display memory usage", and find out how much your pages need.
Also follow the fixes I mentioned, test them and see how much they help you (they give me a few megabytes of savings on the Kickstart install, which still counts).

And of course, find a decent hosting (I don't know if GreenGeeks is decent, don't have much experience in that field), set a decent memory limit, and don't worry too much :)