The secret ended up being running the command as sudo. It's odd how "socket.gethostbyaddr()" worked just fine without sudo, but was slower than nmap.
Update:I installed openmanage with the instructions on this page and used it to check/update bios settings: http://linux.dell.com/repo/community/deb/OMSA_7.1/
The fix ended up being BIOS power profile settings. It was set to Performance Per Watt (DAPC) and needed to be set to "Performance".
Troubleshooting:I have three of the same server. All the servers are Dell r620's with a PERC H710 Mini RAID controller (21.2.0-0007_A04 firmware) and have the exact same hard drives (Seagate ST300MM0006) in RAID 1 configurations. I'm seeing about 50% worse disk read performance on some versions of Ubuntu.
They only differences I can find in the hardware:
- The BIOS version on the poorly performing machines is 1.4.8, the machine that's performing well is on 1.6.0. The BIOS change log doesn't appear to have any changes between the two versions that would affect anything.
- The chipset version on the RAID controller of the poorly performing machines is rev 01 (ChipRevision: B0). The machine that's performing well has the rev 05 chipset (ChipRevision: D1). The motherboard chipset revision is also different.
(mysql read speed test - using the same version of mysql across all 3 machines)
sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --max-time=60 --oltp-read-only=on --max-requests=0 --num-threads=8 run:
(14.04 - rev 01): read/write requests: 1906520 (31773.58 per sec.)
(14.10 - rev 01): read/write requests: 5166798 (86111.50 per sec.)
(13.04 - rev 01) 83886080 bytes (84 MB) copied, 0.116811 s, 718 MB/s
(13.10 - rev 01): 83886080 bytes (84 MB) copied, 0.129371 s, 648 MB/s
(13.04 - rev 05): Timing cached reads:23154 MB in 2.00 seconds = 11589.16 MB/sec
(13.04 - rev 01): Timing cached reads:17934 MB in 2.00 seconds = 8973.68 MB/sec
(13.10 - rev 01): Timing cached reads:18102 MB in 2.00 seconds = 9058.08 MB/sec
(14.04 - rev 01): Timing cached reads:17846 MB in 1.99 seconds = 8956.28 MB/sec
(14.10 - rev 01): Timing cached reads:21538 MB in 2.00 seconds = 10777.93 MB/sec
At one point, 2 of the rev 01 servers were using Ubuntu 14.04 and were getting similar bad benchmark results. After the upgrading them to 14.10, I immediately saw the disk read speed increase.
Here's the closest I can find to a similar issue (it's different hardware though): http://en.community.dell.com/support-forums/servers/f/906/t/19596533
Saw an interesting checklist on Hacker News today that also mentioned disabling BIOS power saving settings: http://odetodata.com/2015/02/installation-and-configuration-checklist-for-microsoft-sql-server/
Solution: Try running as sudo.
If you need to change Putty’s defaults, press “Load” on the saved session for “Default Settings”, make your changes, and “Save”.
- It's up-to-date (as of 12/27/2014). Django-skel is currently at only up to 1.5.9.
- It's minimal. It doesn't make many design decisions for you or include a bunch of junk. Django-base-template isn't as minimal.
- Great structure, it follows this fairly closely: http://stackoverflow.com/a/23469321/1364191
It's definitely a common mistake for people using WTForms. When you create a form and use something like datetime.date.today() as a default value, that value will always stay the same. The fix is to use "datetime.date.today" instead of "datetime.date.today()".
- Set default port=5000 (this seems to be Dokku's default too)
- Set default host=0.0.0.0 (this allows your host server to connect to the container)
In your Procfile:
If you're using gunicorn, it shouldn't matter because it's not using app.run().
If you still can't connect to your application after it deploys, see this: http://www.paulsprogrammingnotes.com/2014/12/troubleshooting-dokku-not-accessible.html
dokku run <your-app> "<whatever is in your proc file>"
Get the :port number from the line with "upstream" in the following file: /home/dokku/<your-app>/nginx.conf
Try to "wget 127.0.0.1:<your-port>" from the host. Will it connect?
This was due to a connection error between my docker container and the internet. To determine this, I ran "docker images" and got the image id of "programium/buildstep", then got into a container with the following command: sudo docker run -t -i <your image id> /bin/bash
Once in the container, I ran:
curl http://lang-python.s3.amazonaws.com/cedar/runtimes/python-2.7.8.tar.gz -s
If that is unsuccessful, that should confirm it's a connection issue.
This was the solution to the problem: http://www.paulsprogrammingnotes.com/2014/12/rebuilding-buildstep-image-for-dokku.html
I had to change the buildstep image’s docker file to add my proxy. This is because the buildstep image required a proxy before the build to download the python buildpack.
I was rebuilding the buildstep image for dokku with these instructions: https://github.com/progrium/dokku/commit/9ebf453b72cab3a16ea261284236bb7c20ca3a1a#diff-04c6e90faac2675aa89e2176d2eec7d8R101
I’m behind a proxy, so I was getting this error when I ran “sudo make build”:
Cloning into ‘heroku-buildpack-multi’… fatal: unable to access ‘https://github.com/ddollar/heroku-buildpack-multi.git/’: Failed to connect to github.com port 443: Connection timed out
The solution? Replace the Dockerfile in the root of the folder you git cloned with this: