Chase Seibert's questions

We have an existing web application at www.example.com. The marketing team has a hosted Drupal instance at marketing.example.com. Is there a reverse-proxy solution that would allow me to serve up the marketing content from www.example.com/marketing?

I would like to do this with networking infrastructure changes only; ie NOT changing either the marketing site base url configuration, or adding code to www.example.com.

In Varnish, I can do something like:

if (req.url ~ "^/marketing/") {
  set req.host = "marketing.example.com";
  set req.url = regsub(req.url, "^/marketing/", "/");
} 

However, marketing.example.com is serving up HTML with absolute links like "/blog", that now need to be updated to "/marketing/blog". Could the reverse proxy re-write these links, but keep asking the marketing backend for "/blog"?

Again, I don't want to change the configuration of the marketing site to respond to the new URL format itself. I want the reverse proxy to handle all that.

Right now we're using Varnish, but I'm open to other solutions.

I have a custom Django app that's becoming unresponsive roughly every 5,000 requests. In the apache logs, I see see the following:

Apr 13 11:45:07 www3 apache2[27590]: **successful view render here**
...
Apr 13 11:47:11 www3 apache2[24032]: [error] server is within MinSpareThreads of MaxClients, consider raising the MaxClients setting
Apr 13 11:47:43 www3 apache2[24032]: [error] server reached MaxClients setting, consider raising the MaxClients setting
...
Apr 13 11:50:34 www3 apache2[27617]: [error] [client 10.177.0.204] Script timed out before returning headers: django.wsgi
(repeated 100 times, exactly)

I believe I am running WSGI 2.6 (/usr/lib/apache2/modules/mod_wsgi.so-2.6) with the following config:

apache config

WSGIDaemonProcess site-1 user=django group=django threads=50
WSGIProcessGroup site-1
WSGIScriptAlias / /somepath/django.wsgi

/somepath/django.wsgi

import os, sys
sys.path.append('/home/django')
os.environ['DJANGO_SETTINGS_MODULE'] = 'myapp.settings'    
import django.core.handlers.wsgi    
application = django.core.handlers.wsgi.WSGIHandler()

When this happens, I can kill the wsgi process and the server will recover.

>ps aux|grep django # process is running as user "django"
django   27590  5.3 17.4 908024 178760 ?       Sl   Apr12  76:09 /usr/sbin/apache2 -k start
>kill -9 27590

This leads me to believe that the problem is a known issue:

deadlock-timeout=sss (2.0+)

Defines the maximum number of seconds allowed to pass before the daemon process is shutdown and restarted after a potential deadlock on the Python GIL has been detected. The default is 300 seconds. This option exists to combat the problem of a daemon process freezing as the result of a rouge Python C extension module which doesn't properly release the Python GIL when entering into a blocking or long running operation.

However, I'm not sure why this condition is not clearing automatically. I do see that the script timeout occurs exactly 5 minutes after the last successful page render, so the deadlock-timeout is getting triggered. But it does not actually kill the process.

Edit: more info

• apache version 2.2, using the worker MPM
• wsgi version 2.8
• SELinux NOT installed l
• xml package being used, infrequently
• Ubuntu 10.04

I'm looking to backup a postgres database to a plaintext file, and then restore that backup. Here is what I tried.

sudo -u postgres pg_dump --create mydatabase > backup.sql
sudo -u postgres psql < backup.sql

I want the database to be completely restored to the state it was in when I backed it up. I'm expecting it to issue a DROP DATABASE in backup.sql, but this is not happening.

Currently, my work-around is to edit backup.sql and insert a DROP DATABASE. Is that really necessary?

The mysql slow query log shows query time in whole integers.

# Query_time: 0  Lock_time: 0  Rows_sent: 177  Rows_examined: 177
SELECT ...
# Query_time: 1  Lock_time: 0  Rows_sent: 56  Rows_examined: 208
SELECT ...

There was a microsecond patch to allow mysql to be configured to log queries that take longer than X microseconds to run. But is there a way to have the log output the query time in either milliseconds or microseconds?

We have a Windows 2008 file server that's going off-line intermittently. When it's down, the Windows 2003 web servers pile up requests with pending file operations.

I ran some tests using ColdFusion, and I noticed that if you request a file on a known-down or non-existent server, the initial request takes 15 seconds to timeout. Subsequent requests fail quickly for the next 10 seconds or so. Then there is another 15 second timeout, and the pattern repeats.

I would like to configure both the maximum amount of time a request to a non-existent server can take (the 15 seconds), as well as how long the fact that the server is down is cached (the 10 seconds).

Is this something can can be tuned on Windows clients?

Edit: I got a capture from Wireshark showing Netbios naming service packets:

No.     Time        Source                Destination           Protocol Info
     90 2.184614    172.27.8.7            172.27.8.255          NBNS     Name query NB CHASE-IE<20>
     97 2.920946    172.27.8.7            172.27.8.255          NBNS     Name query NB CHASE-IE<20>
    106 3.671325    172.27.8.7            172.27.8.255          NBNS     Name query NB CHASE-IE<20>
    136 12.936379   172.27.8.7            10.0.2.15             NBNS     Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
    140 14.436181   172.27.8.7            10.0.2.15             NBNS     Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
    142 15.936134   172.27.8.7            10.0.2.15             NBNS     Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>

You can see the 15 seconds the initial request is taking. It looks like it does a UDP broadcast to the whole subnet (172.27.8.255). It doesn't get an answer, and then somehow gets the right IP (10.0.2.15), perhaps via DNS. Then it spends a few seconds timing out to that server (it's offline).