All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
What response time do you expect on cancelation requests?
November 25th 4:35AM EST : sent ticket to cancel 50GB serversync account as I no longer need it, and performance was getting too slow anyways, takes like 2 seconds just to do an ls of a small folder [drives were at like 92% capcity of their 7,385,465MB /dev/sdb3], there's no link/button to cancel out a service, so have to submit a ticket.
November 26th 12:32AM EST : received my notice that an invoice has been generated for the service.
November 29th 12:30AM EST : received an invoice reminder letting me know it's due on the 1st.
Ticket Status: Open, no response.
On the plus side I don't have a payment arrangement with them (ie: I pay it as I get invoiced, no automated billing), but at the same time should it really take nearly a business week to respond to a simple cancelation? Thanksgiving weekend was last week, not this week.
I remember vaguely someone else mentioning the same thing when they submitted a cancelation with Accunett/Serversync.
Comments
Instant or within 12-24 hours.
Since I still have access I figured I'd do some dd tests to prove a point on just how slow it's been despite the :
Other providers use only single parity RAID5.
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 26.8879 seconds, 39.9 MB/s
... course doing /dev/zero is easily cached so tried random
was taking forever so I canceled it with ctrl+c (did 4k x 1k simply cuz previous test were just staying forever so I thought I'd try small...)
dd if=/dev/random of=test bs=4k count=1k conv=fdatasync
copied, 149.447 seconds, 0.0 kB/s
0+8 records in
0+8 records out
78 bytes (78
figured maybe I need to do a non-blocking device like /dev/urandom with 4k x 4k
dd if=/dev/urandom of=test bs=4k count=4k conv=fdatasync
4096+0 records in
4096+0 records out
16777216 bytes (17 MB) copied, 5.17345 seconds, 3.2 MB/s
now a read/write of that to test2
dd if=test of=test2 bs=4k count=4k conv=fdatasync
4096+0 records in
4096+0 records out
16777216 bytes (17 MB) copied, 0.207457 seconds, 80.9 MB/s
Now back to random write
dd if=/dev/urandom of=test3 bs=4k count=4k conv=fdatasync
4096+0 records in
4096+0 records out
16777216 bytes (17 MB) copied, 3.52781 seconds, 4.8 MB/s
It even took 10 seconds from typing rm on a 50MB file to complete. Guessing support staff isn't the only thing slow.
Cancellation should be automatic whenever their next cronjob runs or at the end of my billing cycle (whichever option I specify in WHMCS).
Yea they're using WHMCS branded, which is why I'm wondering such an automated method doesn't exist.
They can select you mean, I know how to do it if I were running WHMCS myself. And I would think 24-hour and/or end of billing period is more than ample time since most people tend to backup/move their stuff before they submit a cancelation notice.
What's odd is on my account page:
But then if I go up to Support tab then Tickets
When you go to my services in WHMCS, click on the product detail and scroll down to the bottom of the page - is there a "request cancellation" button there?
Cancellations in WHMCS should be automatic, no need to open tickets for this.
As for your /dev/random and /dev/urandom tests above - they mean nothing. /dev/random blocks because there is not enough entropy, and the /dev/urandom is slow because there are a lot of calculations involved when generating the pseudo random numbers. You can try dd if=/dev/urandom of=/dev/null bs=64k count=4k and see how fast it goes without writing to the disk at all.
Zilch
There's just an upgrade/downgrade selection, which course can only go up (even though I'm one up from the bottom), and course now that the invoice generated doesn't let you even access that page, and no where on the service page for that product is a cancelation button, request, link etc.
In regards to this:
[email protected] [~]# dd if=/dev/urandom of=/dev/null bs=64k count=4k
4096+0 records in
4096+0 records out
268435456 bytes (268 MB) copied, 45.0436 seconds, 6.0 MB/s
Tried to do free -m, but got permission denied, but can do top
top - 02:18:04 up 204 days, 19:03, 5 users, load average: 5.72, 5.17, 3.40
Tasks: 339 total, 1 running, 336 sleeping, 0 stopped, 2 zombie
Cpu(s): 1.1%us, 2.6%sy, 1.8%ni, 35.1%id, 58.3%wa, 0.2%hi, 0.8%si, 0.0%st
Mem: 2058576k total, 2047492k used, 11084k free, 37852k buffers
Swap: 8150736k total, 365128k used, 7785608k free, 1617216k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22056 dmitriy 18 0 71776 5996 3960 S 0.7 0.3 0:00.02 php
9637 root 20 4 92232 3280 2544 S 0.0 0.2 0:00.03 sshd
11194 root 20 4 93012 3276 2544 S 0.0 0.2 0:00.03 sshd
18473 root 20 4 92232 3268 2532 S 0.0 0.2 0:00.02 sshd
8686 root 20 4 92232 3256 2528 S 0.0 0.2 0:00.03 sshd
17733 root 20 4 92232 3256 2528 S 0.0 0.2 0:00.03 sshd
20609 root 20 4 92232 3260 2528 S 0.0 0.2 0:00.05 sshd
19121 root 20 4 92228 3244 2516 S 0.0 0.2 0:00.04 sshd
22057 mailnull 18 0 113m 4380 2332 D 1.7 0.2 0:00.05 exim
18086 mailnull 15 0 60820 2320 2164 S 0.0 0.1 0:00.25 exim
11642 root 15 0 74040 5388 2112 S 0.0 0.3 0:41.68 cpsrvd-ssl
2481 root 20 4 92232 2128 1908 S 0.0 0.1 0:00.95 sshd
2281 root 5 -10 5092 3040 1896 S 0.0 0.1 0:04.16 iscsid
516 root 20 4 92232 1780 1776 S 0.0 0.1 0:00.03 sshd
531 root 20 4 92232 1848 1776 S 0.0 0.1 0:00.03 sshd
581 root 20 4 92232 1780 1776 S 0.0 0.1 0:00.02 sshd
776 root 21 4 92232 1780 1776 S 0.0 0.1 0:00.03 sshd
1944 root 20 4 92232 1780 1776 S 0.0 0.1 0:00.03 sshd
1966 root 20 4 92232 1780 1776 S 0.0 0.1 0:00.05 sshd
2338 root 20 4 92232 1780 1776 S 0.0 0.1 0:00.03 sshd
3399 root 20 4 92232 1780 1776 S 0.0 0.1 0:00.02 sshd
and df -hm is currently
[email protected] [~]# df -hm
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/sdb3 7385465 6639204 670020 91% /
/dev/sdb1 1984 68 1815 4% /tmp
/dev/sda1 190 26 155 15% /boot
tmpfs 1006 0 1006 0% /dev/shm
Would appear they're using 2GB of ram on a cpanel server with roughly 7TB of storage (I'm on a 50GB storage plan). I count about 188 sshd processes running.
/cat/proc shows AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (dual-core 1ghz)
Then just turn off your VPS and do nothing. You've already sent them a cancellation request before the next billing period started, it's their problem how to handle it now. It wouldn't hurt to reread their ToS too and see if there is something about cancellations there, but even if there is - you've already done what you should normally do so shouldn't need to be worried about this anymore.
It's not a VPS, it's a cpanel login for remote storage, cannot be "turned off", I've already deleted my stuff from my home folder.
This is the dmesg output of their sync5.serverchamber.com
http://pbin.be/show/1025/