errors running /usr/local/bin/update_mercury.sh

Events happening in the community are now at Drupal community events on www.drupal.org.
Greg Coit's picture

If you see this when running /usr/local/bin/update_mercury.sh:

bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.

The issue appears to be how I updated 1.1 with code from trunk. The fix is to run the following commands (assuming you're running 1.1):

sudo /etc/init.d/bcfg2-server stop
sudo rm /var/lib/bcfg2
sudo bzr branch lp:pantheon/1.1 /var/lib/bcfg2
echo -e "<Clients version=\"3.0\">\n</Clients>" | sudo tee -a /var/lib/bcfg2/Metadata/clients.xml
sudo /etc/init.d/bcfg2-server start; tail -f /var/log/syslog

Now you can run /usr/local/bin/update_mercury.sh and all updates will be applied.

Greg

Comments

Problem with Mercury update

macmladen's picture

I was experimentig a lot with various distributions (foremost Debian Lenny and Squeeze, also CentOS and Ubuntu that worked after all).

bzr was major problem, getting it to work and then, versions of packages also.

Suggestion 1: It would be nice to have list of packages needed with versions so that someone could try to build it on other foundation like Debian, FreeBSD, Mac OS X, OpenWallLinux, etc.

Suggestion 2: Some packages along with dependencies bloat installed base and services too. That consumes memory and resources and would be nice to free up some things that are not needed for Mercury (if any, not sure, just asking).

After much trouble, I got it working under Ubuntu Server 10.04 i386 and followed your instructions from [#70268] but failed at sudo /etc/mercury/init.sh. I removed manually update_mercury.sh and update_pressflow.sh and everything finished after all and site was working.

I got bcfg2-server time-out error, even after I restarted server (I know it is not windows, but could help).

I know Debian is a bit more conservative but it would be nice to have some kind of procedure for it (where could be used repos like backports and maybe squeeze)

Suggestion 3: I'd like to have instructions to build mercury from source, manualy, so I can fine tune Apache, PHP, MySQL and all other elements without overhead of servers like bcfg2 et al with configuration files and other things so that Mercury could be deloyed anywhere.

Suggestion 4: Now my task is to integrate Aegir into my hardly build Mercury. I haven't found some easy to follow instructions (it is either Aegir or Pantheon). Besides, there was Mercury, Pantheon and Vulkan and the later two just disappeared.

Anyway, BIG thank you for this development and effort, I'm not sure as how could I optimize it so well as you did. I'm as yet to make comparison of speed of the two, Mercury and just plain, out of box LAMP.

_______________
Use Mac.

Mladen Đurić
Web Development.

re: Problem with Mercury update

Greg Coit's picture

I was experimentig a lot with various distributions (foremost Debian Lenny and Squeeze, also CentOS and Ubuntu that worked after all).

bzr was major problem, getting it to work and then, versions of packages also.

We recently released instructions for centos 5.x (http://groups.drupal.org/node/80244), and are working on one for Debian Lenny.

Suggestion 1: It would be nice to have list of packages needed with versions so that someone could try to build it on other foundation like Debian, FreeBSD, Mac OS X, OpenWallLinux, etc.

If you look in /var/lib/bcfg2/Bundler/ you'll see the packages that every part of Mercury requires. However, Mercury is more than just the packages, it's also config files that are tuned for best performance.

Suggestion 2: Some packages along with dependencies bloat installed base and services too. That consumes memory and resources and would be nice to free up some things that are not needed for Mercury (if any, not sure, just asking).

To mitigate this issue, we don't install "recommened" packages, just "required". We also have a file (/etc/mercury/server_tuneables) that allows one to turn off unwanted services.

After much trouble, I got it working under Ubuntu Server 10.04 i386 and followed your instructions from [#70268] but failed at sudo /etc/mercury/init.sh. I removed manually update_mercury.sh and update_pressflow.sh and everything finished after all and site was working.

I got bcfg2-server time-out error, even after I restarted server (I know it is not windows, but could help).

Was the time-out error the issue with update_mercury.sh and update_pressflow.sh (well, the former since the latter doesn't call bcfg2)? Sounds like either bcfg2-server wasn't running at all, or there were 2 instances of it running.

I know Debian is a bit more conservative but it would be nice to have some kind of procedure for it (where could be used repos like backports and maybe squeeze)

It's coming, but right now the press is to get Mercury 1.1 out the door.

Suggestion 3: I'd like to have instructions to build mercury from source, manualy, so I can fine tune Apache, PHP, MySQL and all other elements without overhead of servers like bcfg2 et al with configuration files and other things so that Mercury could be deloyed anywhere.

Mercury is designed for non-system administrators. If you are a system administrator and want more control, there are plenty of instructions out there for making high-performance drupal sites. Or, you can use Mecury and turn the bcfg2 server off once the system is setup. Or one can configure service resources (mostly memory usage) using /etc/mercury/server_tuneables.

Suggestion 4: Now my task is to integrate Aegir into my hardly build Mercury. I haven't found some easy to follow instructions (it is either Aegir or Pantheon). Besides, there was Mercury, Pantheon and Vulkan and the later two just disappeared.

Mercury and Vulcan are projects within Pantheon. And yes, almost all our focus has been on Mercury, but my guess is that we're going to see vulcan (aka hudson and continuous integration) built into Mercury someday.

Hope this helps,

Greg

--
Greg Coit
Systems Administrator
http://www.chapterthree.com

Further suggestions

macmladen's picture

First of all, thanks for response, it is always encouraging too see key developer and architect in active reply!

I have seen that Debian is on your timeline and I fully support that as Lenny is really unbloated, responsive and has platform support that others can hardly imagine (waiting to check how is my old PowerPC G4 dual 1GHz performing).

As Mercury is quite a tweaking, it would be nice to see some benchmarking and system suggestion, requirements.

Sure, I know, it depends on lot of things for both tasks but it is something every starter is thinking about with these questions:

  1. How faster system will be? comparing to plain LAMP stack, page hits, users, which or what kind of modules scales better, which or what kind of use will degrade Mercury. It would be nice to have some benchmarking method, maybe like Using JMeter to test performance of Drupal with authenticated users.
  2. What system do I need as far as I have tested, anything less than 1GB (plain OS install uses ~30MB of memory, but after Mercury is set up, free gives ~490 used on 512MB machine) also how performance scales (at least approximately).
  3. What OS, 32 or 64 64 bits eats more memory but what is penalty/benefit ratio? Which one is better and what does that depend?
  4. What about other http engines like lighttpd or nginx, many say they are faster, are they better for Mercury? Have you tried them?
  5. What about boost module it is not mentioned anywhere, is it good for Mercury, does it help?

Drupal is quite demanding in resources, both memory and processing power so one cannot just go for low VPS and have anything meaningfull not to mention high performance like Mercury. Some documentation may be misleading if not stressing enough requirements.

Mercury is designed for non-system administrators.

I would like to think that way but Mercury is surely no DrupalGarden :D Seriously, I doubt that casual user can get installation done unless it is StackScript or AMI. There we come to another thing,

If you are a system administrator and want more control, there are plenty of instructions out there for making high-performance drupal sites.

I was looking at various places but essentialy only yours from [#70268] gets one going (unless using disk images).

I think Mercury is for those who are one step further in both Drupal and linux system administration and there are no easy ways to control or monitor performance so it is not a hobby or n00bie play and therefore should be more geared toward big heads.

I am looking at Mercury because I figured out I need to move from low cost shared hosting to VPS and once there I want to squeeze the most I can from that VPS.

Therefore Mercury and Aegir both goes hand in hand with Pressflow, APC, Varnish, solr and other boosters.

Lastly,

Suggestion 5: I read somewhere about even more speeding things (and optimising server) with using boost module and using nginx for static pages and anonimous visitors, while apache serves authenticated. What do you think about that?

_______________
Use Mac.

Mladen Đurić
Web Development.

re: Further suggestions

Greg Coit's picture

How faster system will be? comparing to plain LAMP stack, page hits, users, which or what kind of modules scales better, which or what kind of use will degrade Mercury. It would be nice to have some benchmarking method, maybe like Using JMeter to test performance of Drupal with authenticated users.

We've released some stats in this group before as to performance(http://groups.drupal.org/node/34076), and the jmeter scripts we're using (http://groups.drupal.org/node/53963).

What system do I need as far as I have tested, anything less than 1GB (plain OS install uses ~30MB of memory, but after Mercury is set up, free gives ~490 used on 512MB machine) also how performance scales (at least approximately).

RAM is Mercury's best friend. 512 is the minimum required, but the minimum for your site depends on the size and usage of the site.

What OS, 32 or 64 64 bits eats more memory but what is penalty/benefit ratio? Which one is better and what does that depend?

Testing this on AWS is not simple since the 64-bit serves come with much more RAM. We should have the answer to this question by the time we release Mercury for Rackspace Cloud.

What about other http engines like lighttpd or nginx, many say they are faster, are they better for Mercury? Have you tried them?

We have done some informal testing. More formal testing is coming.

What about boost module it is not mentioned anywhere, is it good for Mercury, does it help?

Boost and Varnish accomplish the same goal, we choose varnish due to familiarity with the project.

<

blockquote>Suggestion 5: I read somewhere about even more speeding things (and optimising server) with using boost module and using nginx for static pages and anonimous visitors, while apache serves authenticated. What do you think about that?

<

blockquote>

This is very similar to Mercury, in that Varnish serves anonymous requests and Apache server authenticated users.

Hope this helps,

Greg

--
Greg Coit
Systems Administrator
http://www.chapterthree.com

Lack of consolidated information on Mercury

macmladen's picture

Thanks Greg, as this is most helpful I have ever read.

Mercury is like some sort of underground project: its information is spread over High Performance Group, Aegir group, Pantheon group, GetPantheon Site and various VPS providers and individuals posting their findings and experiences.

In past month I have learned that Drupal is no kid for shared hosting play if you plan to have few sites. As your site gets more visitors, FCGI PHP is eating memory rapidly and also CPU so you end up with Page not found 404 error and Internal server 500 error which is then attributed inadequately to cheap hosting.

True, cheap hosting is for cheap: one site on fine crafted Drupal will drive fine no matter which hosting. If one plans more (say 20 sites) with average 10-20 concurrent logged in visitors one will find errors popping more and more. Surely, if you host 10 or more, you'd better be with VPS and there is where Mercury starts.

So if one asks me, it is either some Drupal sites on shared or go for full featured VPS where you can tweak server and live up for thousand concurrent on hundred sites and then grow memory and disk as you need is. Third path is some Cloud server where you can grow your resources (nearly) indefinitely.

As far as I have seen, Amazon, RackSpace and Linode are fine players in VPS area so I wholehearted recommend focusing on this path you already are on, providing Mercury images and scripts to build on whatever system someone like and whatever OS they choose.

It is a hard job, I know, and you guys are doing something that gold couldn't buy and we, commons, could not give you more credit for your work.

Being a developer is a hard one, I know that too, esp if you need to make a living on one side and contribute to free community on a project that can have many faces and yet people expect someone to answer their questions, from n00bs to semi pros (worst case ;) to pros that have some so specific question yet anything could contribute to project at the end of the day.

When semi-pro like me enters the arena it is hard to follow instructions, yet not impossible.

Suggestion 6: What I would like is some kind of gathering information on projects like Mercury/Pantheon, Pressflow and Aegir as one can barely exist without another (why would anyone go on Aegir and not use Mercury as basis? why'd you look to high performance without Pressflow?)

Lets try to have various information on building Mercury, about Mercury and related information in one place. Lets try to cooperate closely as much as possible without interfering others goals on building perfect Drupal stack tailored to ones capabilities or needs (Pressflow for shared hosting, Mercury on Pressflow for VPS, Aegir on Mercury on Pressflow for those rare that do massive hosting).

I am ready (being a freshmen on Mercury) to help sieve various sources of information and post them here on Pantheon group as it seems to be the best place for such information gathering. I see that lot of it is already there under Documentation but still, it is scattered and does not offer information on some philosophy behind the concept in a way that you answered my questions here. (I have done lot of researching and experimenting before I decided to ask and bug you ;)

It is a bit confusing to trace information on GetPantheon site, esp on launchpad which I still do not understand how can I get some information from there except repository. Khalid and 2bits site together with Linode (I'm still not there but I plan to be with my Mercury once finished in house testing) had some fine info.

I am impressed how phase// put up Open Publish site and I believe that is the way GetPantheon should be heading: strong vision of project laid out with fine explanation and good information organization (better that Atrium which is also quite well done).

If there is a way I can help, I'm ready do participate and do my share by returning back to community. I am ready to do some testing, building or comparing as needed.

And lastly, I'd like to give my votes to:

  1. Debian base (which is also Ubuntu base) as it is lighter on hardware and less "rich" in installation which brings down complexity, brings up stability and over all speed and responsiveness.
  2. nginx as I read all the best on speed, responsiveness and security
  3. static caching better explored as I see some opportunity for Boost, reverse proxy like Squid or lighttpd in comparison to Varnish or explanation what are benefits of one technology over other and which technology would better fit what kind of workflow (with possible guide?)

I hope this little discussion will also help many in understanding concepts behind Mercury.

_______________
Use Mac.

Mladen Đurić
Web Development.

Mercury

Group organizers

Group categories

Post Type

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: