Category Archives: How-to

  • 0

Virgin Media Speeds In Nottingham

Category : How-to

Get Social!

Somewhat off-topic today, but something that I’ve recorded here to showcase the current state and see if anyone else is getting similar issues.

A colleague of mine and I have been measuring our broadband speeds since the start of the year. We both live in Nottingham and pay for a residential Virgin Media 200mbps line which I pay approximately £45 each month.

Given the data logged, we’ve concluded that our upload is typically fine at 12mbps but the download varies massively – to the point where single session streaming from Youtube/Netflix is unusable.

This graph shows average download speed per hour which clearly shows the drop during the ‘busy period’

This next one shows the number of counts recorded at a given speed range for the best time (5am) and worse time (9pm). As you can see at 9pm I mostly get between 30mbps and 80mbps

Another way to look at this is via a heatmap showing counts for all speed groups by hour:

We then wondered what the cost implication of this could be, if we only paid for what we got. The table below shows calculations of the cost impact. It is based on cost per month divided by 24 (number of hours) then working out the modified hourly rate based on that percentage.

Being fair, I would ignore speeds where the fluctuation is less than 20% and pay the full price for that hour. An 80% drop in speed is perfectly reasonable in my book and something that probably wouldn’t be noticed by most people. Using the above calculation the result would be a cost of £33.42, meaning I’m overcharged by ~35%.

These are average speeds, and as shown above the download speed can be much lower than this average and it’s at these points the impact to me is most interruptive to me and this cost isn’t reflected above.

How are other peoples download speeds stacking up?


  • 0

Simple iptables Rules for Ubuntu/ Debian VPS

Get Social!

The following iptables rules are are a starting point to add basic firewall security to a public facing server, such as a public VPS. The primary focus is to stop any inbound traffic other than SSH, which is required for shell access.

The biggest issue with public VPS providers is that often some iptables features are disabled – many OpenVZ container providers don’t allow state checking in iptables, for example. If you’ve got one of these VPS’s you’ll likely see the following error:

These rules are engineered so that they will work with most VPS’s where iptables is installed.

The following rules will block all incoming connections except SSH, including PING requests. Outgoing is open for HTTP and HTTPS TCP requests and DNS UDP requests.

See the links at the bottom of the page for a more in depth look at iptables rules.

If you’re using Ubuntu, you can easily make the rules persist:

 


  • 0

Setting Memory Resource Limits With LXC

Category : How-to

Get Social!

linux_containers_logo

 

Linux Container (LXC) management is now often dealt with by LXD, the Canonical lead project built on top of LXC.

LXD offers a suite of options for controlling Linux Container resources and setting limits where appropriate. This post will talk about setting constraints on CPU, however other options are available for limiting almost any sort of resource, such as network, disk I/O, memory and so on.

Available Limits

CPU management is done in 1 of 4 ways, depending on your expected workload and host CPU management regime.

  1. Number of CPUs – set the number of CPU cores that LXC can use with this container and automatically distribute CPU time amongst guests when there is competition for CPU time. The value used is an integer, for example 2.
  2. Specific cores – specify specific physical core(s) for the container to use and distribute available CPU time between containers when multiple containers use the same cores.The value used is an integer or range and can be comma separated, for example 2, 0-1 or 0-1,3,5-9.
  3. Capped share – allow a specified percentage of CPU time for the container, or more if it’s available. When the host is not under load then a container can use any available CPU however when there is contention for CPU then the container will be limited to the specified amount. The container will see all host CPU cores (in TOP, for example).
  4. Limited time share – will limit the container CPU time to be whatever is specified out of each 200ms. Even if more CPU is available, only what is specified per 200ms slice is allowed. The container will see all host CPU cores (in TOP, for example).

Setting Limits

Setting limits is done with the lxc command. There are then two options; limits.cpu for the above points 1 and 2, or limit.cpu.allowance for points 3 and 4.

  • [CONTAINER] is the name of the container – can be obtained from lxc list if you’re unsure.
  • [VALUE] is a valid value from point 1 or 2 above.

OR

  • [CONTAINER] is the name of the container – can be obtained from lxc list if you’re unsure.
  • [VALUE] is a valid value from point 3 or 4 above.

CPU Limit Examples

Set the container nginx-proxy to use any 2 CPUs on the host.

Set the container nginx-proxy to use physical CPU 0, 3, 7, 8 and 9 on the host.

Set the container nginx-proxy to use 20% of the available CPU on the host or more if it’s available.

Set the container nginx-proxy to use no more than 50% of the available CPU on the host, or 100ms for every 200ms of CPU time available.

You can view /proc/cpuinfo to see the available cores on your container, however it will not include any additional scheduling limits or priorities.

CPU Priority

The last option around CPU limiting is the priority of CPU time. This option only kicks in when the host is overcommitted on CPU resource and containers are fighting for CPU time. This can either be on a single core (if using above points 1 or 2) or system wide (if no CPU limiting is in place or using above points 3 or 4).

Available values are 0 – 10 inclusive and lower numbers mean a lower priority – a higher number will mean the machine gets CPU time before lower numbers.

The below command sets the container nginx-proxy to have a CPU priority of 5.

The below command sets the container php-backend to have a CPU priority of 2 and therefore would get less CPU time than container nginx-proxy when CPU is under contention.


  • 0

Setting CPU Resource Limits With LXC

Category : How-to

Get Social!

linux_containers_logoLinux Container (LXC) management is now often dealt with by LXD, the Canonical lead project built on top of LXC.

LXD offers a suite of options for controlling Linux Container resources and setting limits where appropriate. This post will talk about setting constraints on CPU, however other options are available for limiting almost any sort of resource, such as network, disk I/O, memory and so on.

Available Limits

CPU management is done in 1 of 4 ways, depending on your expected workload and host CPU management regime.

  1. Number of CPUs – set the number of CPU cores that LXC can use with this container and automatically distribute CPU time amongst guests when there is competition for CPU time. The value used is an integer, for example 2.
  2. Specific cores – specify specific physical core(s) for the container to use and distribute available CPU time between containers when multiple containers use the same cores.The value used is an integer or range and can be comma separated, for example 2, 0-1 or 0-1,3,5-9.
  3. Capped share – allow a specified percentage of CPU time for the container, or more if it’s available. When the host is not under load then a container can use any available CPU however when there is contention for CPU then the container will be limited to the specified amount. The container will see all host CPU cores (in TOP, for example).
  4. Limited time share – will limit the container CPU time to be whatever is specified out of each 200ms. Even if more CPU is available, only what is specified per 200ms slice is allowed. The container will see all host CPU cores (in TOP, for example).

Setting Limits

Setting limits is done with the lxc command. There are then two options; limits.cpu for the above points 1 and 2, or limit.cpu.allowance for points 3 and 4.

  • [CONTAINER] is the name of the container – can be obtained from lxc list if you’re unsure.
  • [VALUE] is a valid value from point 1 or 2 above.

OR

  • [CONTAINER] is the name of the container – can be obtained from lxc list if you’re unsure.
  • [VALUE] is a valid value from point 3 or 4 above.

CPU Limit Examples

Set the container nginx-proxy to use any 2 CPUs on the host.

Set the container nginx-proxy to use physical CPU 0, 3, 7, 8 and 9 on the host.

Set the container nginx-proxy to use 20% of the available CPU on the host or more if it’s available.

Set the container nginx-proxy to use no more than 50% of the available CPU on the host, or 100ms for every 200ms of CPU time available.

You can view /proc/cpuinfo to see the available cores on your container, however it will not include any additional scheduling limits or priorities.

CPU Priority

The last option around CPU limiting is the priority of CPU time. This option only kicks in when the host is overcommitted on CPU resource and containers are fighting for CPU time. This can either be on a single core (if using above points 1 or 2) or system wide (if no CPU limiting is in place or using above points 3 or 4).

Available values are 0 – 10 inclusive and lower numbers mean a lower priority – a higher number will mean the machine gets CPU time before lower numbers.

The below command sets the container nginx-proxy to have a CPU priority of 5.

The below command sets the container php-backend to have a CPU priority of 2 and therefore would get less CPU time than container nginx-proxy when CPU is under contention.


  • 4

Add systemd Startup Script For CouchDB

Get Social!

couchdb-whiteCurrently, version 2.0 of CouchDB doesn’t come with any form of startup script. I’m sure that as the CouchDB 2 branch becomes more mature and it’s added to the various software repositories startup scripts will be shipped as standard, but until then we have to make do.

The below script is a systemd startup script with a cat command to create the file with the required content in the systemd config directories. Run the below script to create the startup file. You’ll need to change /usr/bin/couchdb to be the location of your couchdb executable.

You’ll then need to reload the systemd daemon and add the couchdb service to the startup routine. Run the below commands to enable CouchDB at machine startup.

 


  • 0

Basic IPTable Rules

Category : How-to

Get Social!

Here are some basic IPTable rules to enable essential connectivity from the host. Outbound connectivity such as ping, DNS and HTTP are all enabled, along with inbound SSH.

All external sources are enabled for SSH so it’s advisable to restrict this further once you’re up and running. This IPTables script is intended to be a starting point and may need to be tailored for your security requirements.

Paste the below script in order to get started.

Optional, run iptables -F to clear existing rules.

 

See the cheat sheet for more information.


Visit our advertisers

Search

Visit our advertisers