On Fri, Apr 30, 2004 at 12:18:39PM +0200, David De Maeyer wrote:
> Hi all,
>
> First of all I would like to say thank you to all of you who answered.
> I didn't try all your suggestions yet, some of them were already
> applied with no success, some others need to be tried... I keep you
> informed.
>
> As a matter of fact, we deal with A LOT of small files which generally
> go along with a slower backup process. We have also tried another
> backup solution to see if we were too blind and... well looks like we
> all are here in our group as the other server just flies! And taking a
> closer look to the network didn't really show anything we didn't know.
>
> The problem for us is that we have no problems with other clients
> running the same OS (file service, web servers, calendar, etc.)
>
> It only affects the mail server. In the past, using a smaller
> workstation and another IMAP server, performances were from far better!
>
> Our preliminary conclusion: our backup server seems to be in trouble
> when dealing with a client hosting tons of small files.
I agree, however I think the client's the bottleneck, not the server. We
had similar mail server on Linux with millions of small files, 200GB on a
single filesystem, and it would get slower over time. We used ext2 at
first, later converted to ReiserFS with a three-fold increase in backup
speed, but have recently ditched reiserfs since its fsck speed was
disastrous (fsck running for 48 hours). Splitting the "All" saveset also
helped somewhat (from 24hr backup window to 16hr). However, in the end we
split the data across two partitions on two different machines which
effectively halved the backup time.
I also noted that the backup is _much_ faster right after the fresh
installation, when all the files are defragmented.
Our restores were extremely slow too, due to multiplexing the slow stream
with faster ones saved to the same tape. This is probably worse than having
slow backups. (We'll try to compensate for that using file devices.)
I would suggest splitting the data on a few separate partitions stored on
separate raid devices, using a symlink farm to recreate the previous tree,
or if you can't do that, try using explicit savesets instead of "All".
Regards,
Zoran
> >>---- Original Message ----
> >>From: David De Maeyer
> >>Hi all!
> >>
> >>We are facing a performance issue when taking a full backup of our
> >>mail
> >>server (>7000 users, 350 GB of data, running Debian linux).
> >>
> >>The backup server has no problem with the other linux clients. It is
> >>writing at around 100 KB/s... which is far from the 2 to 8 MB/s we are
> >>used to have on the other clients.
> >>
> >>It takes forever to backup all the user directories! And we simply
> >>can't find where the bottleneck is... just that there are a lot of I/O
> >>on the RAID on which these directories are stored.
> >>
> >>Would it help to increase/decrease the parallelism for the client
> >>and/or other clients (smaller filesystems)?
> >>
> >>Does somebody on this mailing-list once faced a similar problem? Is
> >>the
> >>upgrade of the client on the mail server a must?
> >>
> >>Regards,
> >>David
> >>
> >>server: NetWorker 7.1.1 (running Solaris 8)
> >>client: NetWorker 6.1.1 (running Debian linux, IMAP server, 350 GB on
> >>external RAID)
> >>
> >>___________________________________________________
> >>David De Maeyer
> >>Roskilde University Center, Department of Computer Science
> >>Box 260, Hus 42.1, 4000 Roskilde, Denmark
> >>voice (+45) 46 74 38 29 / fax (+45) 46 74 30 72
> >>
> >>--
> >>Note: To sign off this list, send a "signoff networker" command via
> >>email
> >>to listserv AT listmail.temple DOT edu or visit the list's Web site at
> >>http://listmail.temple.edu/archives/networker.html where you can
> >>also view and post messages to the list.
> >>=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
> >
> >--
> >Note: To sign off this list, send a "signoff networker" command via
> >email
> >to listserv AT listmail.temple DOT edu or visit the list's Web site at
> >http://listmail.temple.edu/archives/networker.html where you can
> >also view and post messages to the list.
> >=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
> >
> >--
> >Note: To sign off this list, send a "signoff networker" command via
> >email
> >to listserv AT listmail.temple DOT edu or visit the list's Web site at
> >http://listmail.temple.edu/archives/networker.html where you can
> >also view and post messages to the list.
> >=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>
> --
> Note: To sign off this list, send a "signoff networker" command via email
> to listserv AT listmail.temple DOT edu or visit the list's Web site at
> http://listmail.temple.edu/archives/networker.html where you can
> also view and post messages to the list.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Zoran Dzelajlija
System Administrator
Iskon Internet d.d.
Savska 41/X
HR-10000 Zagreb
Croatia
Phone: +385 1 6000 700
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
