One option was missed. Moving to a new web host. Bluehost handles Drupal pretty well, and it has mailman as well. We use anything else? If there is any interest in perusing this, I'm a Bluehost affiliate and I'll gladly donate my affiliate pay to CLUE. <a href="http://www.bluehost.com/track/redmop">http://www.bluehost.com/track/redmop</a> is my affiliate link.<br clear="all">
<br><br>Shawn T Perry<br>Red Mop Computing Services<br>email: <a href="mailto:shawn@redmop.com" target="_blank">shawn@redmop.com</a><br>office: 720-319-7627<br>cell: 303-881-2623<br>web: <a href="http://www.redmop.com/" target="_blank">http://www.redmop.com</a><br>
facebook: <a href="http://www.facebook.com/pages/Red-Mop-Computing-Services/114352628589778" target="_blank">http://www.facebook.com/pages/Red-Mop-Computing-Services/114352628589778</a><br>linkedin: <a href="http://www.linkedin.com/in/shawnperry" target="_blank">http://www.linkedin.com/in/shawnperry</a><br>
<br><br><div class="gmail_quote">On Tue, May 24, 2011 at 6:00 PM, chris fedde <span dir="ltr"><<a href="mailto:chris@fedde.us">chris@fedde.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
What is hindering use of Drupal on the current system is pretty<br>
obvious. It is thrashing because of a shortage of ram for the given<br>
configuration. This conclusion has been vetted by the experiment that<br>
Dennis and I completed on my home system (<a href="http://drupal.fedde.us" target="_blank">http://drupal.fedde.us</a>).<br>
<br>
There are three potential solutions to this problem on the current platform.<br>
* Increase the memory.<br>
* Tune back the memory use of mysql and drupal/PHP so that they don't<br>
use more more than is available.<br>
* Abandon the drupal approach and return to the current technology.<br>
<br>
Solving these technical issues have been complicated by social layer<br>
issues relating to authority, access and transitions in<br>
responsibility. A server committee was called and met.<br>
Recommendations were made on approaches to solving the problem. Notes<br>
from that meeting were posted to the mailing list by our treasurer<br>
(thanks Gus).<br>
<br>
IMHO the conclusions of the server committee's recommendations should<br>
be adopted:<br>
* Adopt Drupal as the forward moving technology solution for CLUE webserver.<br>
* Form an admin group of those able and willing to administer the<br>
server with more than one member.<br>
* Migrate the CLUEDenver.org website to new VPS.<br>
* Design and adopt reasonable server administration practices and<br>
policies to enable group admin.<br>
* Ensure that some practice or policy attempt to address the orderly<br>
transition of admin group members.<br>
<br>
In the interim use of the non Drupal website is exactly the right solution.<br>
<br>
As always helpful commentary is welcome.<br>
<font color="#888888">chris<br>
</font><div><div></div><div class="h5"><br>
On Tue, May 24, 2011 at 5:27 PM, Raymond DeRoo <<a href="mailto:rderoo@deroo.net">rderoo@deroo.net</a>> wrote:<br>
> Gus--<br>
><br>
>> There are better methods to recovering from this issue than what you are doing. Are you consulting with people privately to resolve this ? If so, who are they ? I have not heard any public discussion about how this should be handled.<br>
><br>
> I would say that I tend to agree with Dennis in this matter. The decision to rollback after a week+ of near continuos failure is the correct decision. Whether he made that choice alone, with a private club having a secret handshake, or by "democratic" voting, really doesn't matter from my perspective. I'd rather have a leader make a decision which he feels is in the best interest of the group than be hamstrung because the vocal minority doesn't like the option.<br>
><br>
> That being said, I have offered my services to the group to help assist with the performance issue, especially as there is a real belief that it is related to MySQL. Dennis said he would provide the data. That entire interchange was on this list, so I'm not sure why you wouldn't classify that as a "public discussion". Personally, I'm doubtful this is a MySQL issue, and I would say the issue is most likely with drupal. But the simple fact that the site is running on a VPS mean *ALL* bets are off when it comes to any kind of performance expectations and measurements.<br>
><br>
> Now my offer to help still stands, I would expect that the data points I need would be coming some time next week once the drupal site restored. Gus do you have an ab test suite to stress the drupal install? What monitoring metrics do you suggest? Do you have nagios/munin installed? What problem solving have you done thus far? What have been the results of your findings? What methods do you suggest for providing the needed information to community members and recovering from the current dreadful performance issue?<br>
><br>
> I look forward to your answers as I do not wish to waste times covering areas which you have checked through.<br>
><br>
> .r<br>
> _______________________________________________<br>
> clue mailing list<br>
> <a href="mailto:clue@cluedenver.org">clue@cluedenver.org</a><br>
> <a href="http://cluedenver.org/mailman/listinfo/clue" target="_blank">http://cluedenver.org/mailman/listinfo/clue</a><br>
><br>
_______________________________________________<br>
clue mailing list<br>
<a href="mailto:clue@cluedenver.org">clue@cluedenver.org</a><br>
<a href="http://cluedenver.org/mailman/listinfo/clue" target="_blank">http://cluedenver.org/mailman/listinfo/clue</a><br>
</div></div></blockquote></div><br>