I want to change my VPS 64-bit to 32-bit,Any good mothod ?

hi,

I'm a new one .I frist choose 64-bit VPS host, But now I find it

eat too much MEM

But our website has 1G files, Is there good way

to move it to the new 32-bit VPS host fast ?

             total       used       free     shared    buffers     cached
Mem:        553156     384780     168376          0      20308     162484
-/+ buffers/cache:     201988     351168

8 Replies

I recently went from 32-bit to 64-bit on my Linode.

There is no easy 'click here to switch architectures' button. You'll have to create a new 32-bit profile and rebuild the system.

I found it really helpful to resize the primary disk image for my 32-bit configuration to free up space to create a new disk image. After that, I created a new 64-bit configuration using the profile manager and used the free space to create a new disk. Then, within the 64-bit profile, I mounted the 32-bit drive. I was able to boot into the 64-bit profile, and copy the configuration files from the 32-bit disk.

You might use this opportunity to partition your disk images as you would a server. Most of the Linodes I administer have three disk images –
4. OS in use, like Debian Lenny (2G)

  1. Swap image (256M)

  2. Data (SizeOfPlan - 2304M)
    I then mount Data to /srv and configure all my daemons to serve from there. With this setup, I can fry Lenny, delete it, start over, and still have the server's data in a nice wrapped-up disk image.

Hi there.

Try what Jed mentioned doing. I was also going to suggest that in order to move your host to 32-bit v.s 64-bit, wouldn't it be easiest to actually select a 32-bit Linux profile? Or am I wrong in that assumption. :)

Let me know whatever you think!

Regards, –Keith

@action2001:

             total       used       free     shared    buffers     cached
Mem:        553156     384780     168376          0      20308     162484
-/+ buffers/cache:     201988     351168


According to the above, you are using less than half of the available memory - is there really a problem? Keep in mind that the "-/+ buffers/cache" is the line to watch - this is the memory actually being used by applications.

I'm in the same boat of having invested work in a 64 bit install and wanting to move it to 32 bit to save on memory.

I've always used one giant partition for OS and data but this three partition solution makes a lot of sense. I'm not a Linux or Ubuntu jockey so I have some basic questions.

Once I mount the data partition, how do I make use of it as transparently as possible? For instance, do I symlink /var/ to /srv/var ? /etc to /srv/etc? Which (sub)directories should sit on the OS partition, which on the /srv data partition?

Is this subject covered in a particular book or url on linux administration? TIA.

@jed:

You might use this opportunity to partition your disk images as you would a server. Most of the Linodes I administer have three disk images –
4. OS in use, like Debian Lenny (2G)

  1. Swap image (256M)

  2. Data (SizeOfPlan - 2304M)
    I then mount Data to /srv and configure all my daemons to serve from there. With this setup, I can fry Lenny, delete it, start over, and still have the server's data in a nice wrapped-up disk image.

Also always and I do mean always have /var/log on it's own slice. Having a runway daemon or something creating a huge log and filling up your file system is not a fun thing.

I also keep my web data on it's own slice and also have my db on it's own slice also.

@jed:

I then mount Data to /srv and configure all my daemons to serve from there.

Can you elaborate on what "and configure all my daemons to serve from there" means?

Store your applications data in /srv, either with bound mounts, symlinks, or adjusting your applications configuration files.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct