|
Home > Archive > SQL Anywhere database replication > February 2006 > Changing maximum message sizes on the fly....
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Changing maximum message sizes on the fly....
|
|
| Carol Stone 2006-02-15, 8:23 pm |
| Environment: ASA 7.0.4.3362 (for now)
We have around 100 extracted databases in our company and we have been
using the default message size since we deployed our application. (Oh,
here's a detail you could use: we're using FTP!)
We would like to add the switch -l 50000k to our calls to dbremote. The
documentation says you gotta make sure everyone has that switch set
identically.
Our problem is that dbremote is called from within an application, and
it is not so easy to coordinate so that every last computer gets the new
software on the same day.
From within our application, we call dbremote twice, once with -r and
once with -s. We never run without those switches to let dbremote both
receive and send automatically.
Can we do the following? Or would Sybase strongly recommend against it?
What I would like to do is roll the change out slowly.
First, I would like to set the switch on the receive at the
consolidated to the -l 50000k.
Second, I'd like to roll out our application to the remotes.
At this point, we would be in an environment where the server was
receiving the larger files, and some of the remotes are set to receive
and send the larger files, and some of the remotes are set to receive
and send the smaller files. The server still sends the smaller files.
We wouldn't let this go on for more than maybe five replication cycles -
it's just that there's usually at least one person who can't connect to
the network when they're told to.
Finally, when I'm absolutely sure that everyone has the our new
software, I want to make the final change to the consolidated to send
max 50000k messages.
| |
| Nick Elson 2006-02-15, 8:23 pm |
| The trick here is to simply keep the messages the same size or
smaller than the receiver's -l setting.
Since you have split the -s and -r phases up at the remote
the only big change would be to do so also at the consolidated
site and then execute the following 3 step plan:
1 - run dbremote at the consolated site as follows:
dbremote -s -c <dir>
Note: no change to the -l switch setting just yet!
dbremote -r -c ... -l <new_size> <dir>
Where <new_size> is bigger then the default
or previous size.
1b- This is an good time to consider adding more RAM
to the machine and give dbremote (recieve) more memory
than the default -m size.
2 - Once the consolidated is up (step 1) change the remotes,
as opportunities become available to do so, to use the
larger -l size. You can add this to both phases now to
prevent the need to add it to the receive phase later another
step after this one.
3a - This is an extremly good time to add more RAM to the
machine (if required) and give dbremote (send) more memory
than the default -m size. Since your message size is 1000
times bigger you may find you need a lot more memory to
take advantage of that.
With larger complex transactions you may find dbremote -s
needs a lot more memory all of a sudden.You can add this later,
but if you find that dbremote is sending many small (and
continued) messages, that could be due to having an insufficent
-m setting for your database and replication design.
3b - Once !all! the remotes are up an running with the new -l
setting, switch the consolidated's send phase over to
the new -l setting.
Are you sure you need or can benefit from 50MB messages?
Consolidated databases can typically create much bigger messages than
the remotes so it is absolutely critical it is the very last node to be
changed.
The good news is that if messages are being rejected due to premature
changing of the message size, you can simply unwind these steps one at
a time to the point where it starts working again; after a few resend
cycles message should simply start applying again.
"Carol Stone" <""carol.stone \"@ ctcommunitycare . org"> wrote in message
news:43f3a03d@forums
-1-dub...
> Environment: ASA 7.0.4.3362 (for now)
>
> We have around 100 extracted databases in our company and we have been
> using the default message size since we deployed our application. (Oh,
> here's a detail you could use: we're using FTP!)
>
> We would like to add the switch -l 50000k to our calls to dbremote. The
> documentation says you gotta make sure everyone has that switch set
> identically.
>
> Our problem is that dbremote is called from within an application, and it
> is not so easy to coordinate so that every last computer gets the new
> software on the same day.
>
> From within our application, we call dbremote twice, once with -r and once
> with -s. We never run without those switches to let dbremote both receive
> and send automatically.
>
> Can we do the following? Or would Sybase strongly recommend against it?
>
> What I would like to do is roll the change out slowly.
>
> First, I would like to set the switch on the receive at the
> consolidated to the -l 50000k.
>
> Second, I'd like to roll out our application to the remotes.
>
> At this point, we would be in an environment where the server was
> receiving the larger files, and some of the remotes are set to receive and
> send the larger files, and some of the remotes are set to receive and send
> the smaller files. The server still sends the smaller files.
>
> We wouldn't let this go on for more than maybe five replication cycles -
> it's just that there's usually at least one person who can't connect to
> the network when they're told to.
>
> Finally, when I'm absolutely sure that everyone has the our new
> software, I want to make the final change to the consolidated to send max
> 50000k messages.
| |
| Carol Stone 2006-02-17, 7:24 am |
| Nick Elson wrote:
> Are you sure you need or can benefit from 50MB messages?
>
We were wondering if there is a size that Sybase recommends. We didn't
pick this size scientifically. We had resources scheduled to use our
tester environment and we applied a passthrough which the tester
environment refused to send because the message size was too small.
Fearing the loss of said resources, we just pushed the size up to the
maximum and gave them an interim build of our application.
We have discovered that the larger message size makes the receive
process go faster, because one big file copies faster than a couple
hundred little ones. So we do want to increase the size of the message
files. But we really don't know by how much.
Which brings me to what happened to make us need a larger size, because
it's really strange what we were doing.
We discovered we were updating the primary key of a table at the
remotes. We can't leave it like this because when we upgrade to ASA9, it
won't work any more. So we came up with a band-aid idea and ran a
passthrough in our test environment.
First we passed through the alter table statement to drop the primary
key and the second alter table statement to add a new column. Then we
called "passthrough stop."
Next we updated the contents of the column so it wasn't empty any more.
Then we started another passthrough and added the trigger and applied
the new primary key before issuing passthrough stop again.
Of course, the next morning my co-worker got in before me and figured
out that in order to get our test network up and running he would either
have to recover the whole thing back to before my passthrough
(including all the remotes) or increase the message size, run a new
build, and get that code pushed through to the remotes. He did the
latter, but of course, since it required a new build of the application,
he just picked the largest size message he could. In his shoes, I
probably would have done the same thing.
But now we're all sitting around scratching our heads wondering, what
size *should* the message size be? Is there a way to avoid needing a
larger message size and still change the primary key on this table? (The
table, by the way, had been very hastily converted from a slow view
several years ago for performance purposes. The data is all duplicated
someplace else, and the table *could* be re-built from scratch, if
necessary. The existing table and columns, however, must exist on the
remotes when we run the application.)
So please let me know if we're just going about this all wrong-headed in
the first place! This business of putting in a dirty fix to fix a
problem caused by a dirty fix does strike me as a bad idea.
-carol
| |
| Reg Domaratzki \(iAnywhere Solutions\) 2006-02-17, 9:23 am |
| Recommending a message size depends on many factors :
1) The reliability of your message transport
2) The send and receive frequencies of dbremote at the consolidated and
remote
3) The volume of messages being generated
The first point is the most important. If you're dialing up from a phone
line in a hotel in Nigeria, and need to write 5MB of messages to an FTP
server, odds are your connection will drop at some point. If you're using a
smaller message size, then you may have written 40 messages already and can
start on the 41st when you connect the next time. If you've written 80% of
a 5MB file, you need to start from scratch again.
The send and receive frequencies need to be considered to avoid what I call
"message contention". Image a remote writing a 5MB file to network share
located on the same machine as the consolidated database. If the receive
phase of dbremote on the consolidated fires off while the message is being
written by the remote, it's possible that dbremote on the consolidated will
be able to process the SQL in the message file faster than the remote can
write the file. dbremote on the consolidated may get to what it thinks is
the end of the file, read the last operation which will likely be truncated,
report a SQL Error and give up. SQL Remote will recover after a resend
request, but if the remote only sends once a week, you've possibly added a
lot of latency to your system. This is really the only issue with larger
message sizes in a reliable message transport.
Of course, if the volume of messages you're sending is small, the above two
points don't really come into play.
--
Reg Domaratzki, Sybase iAnywhere Solutions
Sybase Certified Professional - Sybase ASA Developer Version 8
Please reply only to the newsgroup
iAnywhere Developer Community : http://www.ianywhere.com/developer
iAnywhere Documentation : http://www.ianywhere.com/developer/product_manuals
ASA Patches and EBFs : http://downloads.sybase.com/swd/base.do
-> Choose SQL Anywhere Studio
-> Set filter to "Display ALL platforms IN ALL MONTHS"
"Carol Stone" <""carol.stone \"@ ctcommunitycare . org"> wrote in message
news:43f4f801@forums
-2-dub...
> Nick Elson wrote:
>
> We were wondering if there is a size that Sybase recommends. We didn't
> pick this size scientifically. We had resources scheduled to use our
> tester environment and we applied a passthrough which the tester
> environment refused to send because the message size was too small.
> Fearing the loss of said resources, we just pushed the size up to the
> maximum and gave them an interim build of our application.
>
> We have discovered that the larger message size makes the receive
> process go faster, because one big file copies faster than a couple
> hundred little ones. So we do want to increase the size of the message
> files. But we really don't know by how much.
>
> Which brings me to what happened to make us need a larger size, because
> it's really strange what we were doing.
>
> We discovered we were updating the primary key of a table at the
> remotes. We can't leave it like this because when we upgrade to ASA9, it
> won't work any more. So we came up with a band-aid idea and ran a
> passthrough in our test environment.
>
> First we passed through the alter table statement to drop the primary
> key and the second alter table statement to add a new column. Then we
> called "passthrough stop."
>
> Next we updated the contents of the column so it wasn't empty any more.
>
> Then we started another passthrough and added the trigger and applied
> the new primary key before issuing passthrough stop again.
>
> Of course, the next morning my co-worker got in before me and figured
> out that in order to get our test network up and running he would either
> have to recover the whole thing back to before my passthrough
> (including all the remotes) or increase the message size, run a new
> build, and get that code pushed through to the remotes. He did the
> latter, but of course, since it required a new build of the application,
> he just picked the largest size message he could. In his shoes, I
> probably would have done the same thing.
>
> But now we're all sitting around scratching our heads wondering, what
> size *should* the message size be? Is there a way to avoid needing a
> larger message size and still change the primary key on this table? (The
> table, by the way, had been very hastily converted from a slow view
> several years ago for performance purposes. The data is all duplicated
> someplace else, and the table *could* be re-built from scratch, if
> necessary. The existing table and columns, however, must exist on the
> remotes when we run the application.)
>
> So please let me know if we're just going about this all wrong-headed in
> the first place! This business of putting in a dirty fix to fix a
> problem caused by a dirty fix does strike me as a bad idea.
>
> -carol
>
| |
| Nick Elson 2006-02-20, 11:23 am |
| As Reg correctly points out, the answer is
It depends. [Ok, I summarize here. Nigeria aside ;-]
One other big factor is the size of your transactions. At
5MB, if all your applications are running with autocommit
you'd be hard press to generate 20KB (even with 1KB
rows and an application that only does inserts] since
there each transaction would only be 1 Ins/Upd/Del operation
and the default setting for -g is just 20 transactions.
If on the other hand you find you are currently producing
*many* 'continued transactions' [regular messages identified
with a high sequence number M in the dbremote -o logs
"{Sending/Received} message (n-nnnnnnnnnn-nnnnnnnnnn-M)"
then increasing message size could be much more beneficial.
Of course increasing -m (at least at the consolidated site) would
be beneficial in this case too.
"Reg Domaratzki (iAnywhere Solutions)" <FirstName.LastName@ianywhere.com>
wrote in message news:43f5f02c$1@foru
ms-1-dub...
> Recommending a message size depends on many factors :
>
> 1) The reliability of your message transport
> 2) The send and receive frequencies of dbremote at the consolidated and
> remote
> 3) The volume of messages being generated
>
> The first point is the most important. If you're dialing up from a phone
> line in a hotel in Nigeria, and need to write 5MB of messages to an FTP
> server, odds are your connection will drop at some point. If you're using
> a
> smaller message size, then you may have written 40 messages already and
> can
> start on the 41st when you connect the next time. If you've written 80%
> of
> a 5MB file, you need to start from scratch again.
>
> The send and receive frequencies need to be considered to avoid what I
> call
> "message contention". Image a remote writing a 5MB file to network share
> located on the same machine as the consolidated database. If the receive
> phase of dbremote on the consolidated fires off while the message is being
> written by the remote, it's possible that dbremote on the consolidated
> will
> be able to process the SQL in the message file faster than the remote can
> write the file. dbremote on the consolidated may get to what it thinks is
> the end of the file, read the last operation which will likely be
> truncated,
> report a SQL Error and give up. SQL Remote will recover after a resend
> request, but if the remote only sends once a week, you've possibly added a
> lot of latency to your system. This is really the only issue with larger
> message sizes in a reliable message transport.
>
> Of course, if the volume of messages you're sending is small, the above
> two
> points don't really come into play.
>
> --
> Reg Domaratzki, Sybase iAnywhere Solutions
> Sybase Certified Professional - Sybase ASA Developer Version 8
> Please reply only to the newsgroup
>
> iAnywhere Developer Community : http://www.ianywhere.com/developer
> iAnywhere Documentation :
> http://www.ianywhere.com/developer/product_manuals
> ASA Patches and EBFs : http://downloads.sybase.com/swd/base.do
> -> Choose SQL Anywhere Studio
> -> Set filter to "Display ALL platforms IN ALL MONTHS"
>
>
> "Carol Stone" <""carol.stone \"@ ctcommunitycare . org"> wrote in message
> news:43f4f801@forums
-2-dub...
>
>
| |
| Carol Stone 2006-02-25, 9:41 am |
| Good grief, thank you for the info!
We've noticed that in our tester environment, we still get messages
which aren't very large at all mixed in with large messages. Am I wrong
to interpret this as indicating the message size varies with need?
On a very bad day, the M size in:
"{Sending/Received} message (n-nnnnnnnnnn-nnnnnnnnnn-M)"
can be over 1,000. We had one unfortunate incident where the number was
greater than the number of message files which can be generated before
the naming rolls over (starting at .0 and ending at .zzz). Fortunately
that was in the test envrionment!
Our dialup users are nearly all in-state. And when we expect that 'M'
size to be really high, we recommend our users drive into the office to
use the LAN.
This is starting to sound to me like the largest size might be small
enough for our needs. I think we're going to have to beat up our tester
environment and see what happens under load testing! Thank you so much
for the info!
-carol
Nick Elson wrote:
> As Reg correctly points out, the answer is
>
> It depends. [Ok, I summarize here. Nigeria aside ;-]
>
> One other big factor is the size of your transactions. At
> 5MB, if all your applications are running with autocommit
> you'd be hard press to generate 20KB (even with 1KB
> rows and an application that only does inserts] since
> there each transaction would only be 1 Ins/Upd/Del operation
> and the default setting for -g is just 20 transactions.
>
> If on the other hand you find you are currently producing
> *many* 'continued transactions' [regular messages identified
> with a high sequence number M in the dbremote -o logs
>
> "{Sending/Received} message (n-nnnnnnnnnn-nnnnnnnnnn-M)"
>
> then increasing message size could be much more beneficial.
> Of course increasing -m (at least at the consolidated site) would
> be beneficial in this case too.
>
>
>
> "Reg Domaratzki (iAnywhere Solutions)" <FirstName.LastName@ianywhere.com>
> wrote in message news:43f5f02c$1@foru
ms-1-dub...
>
>
| |
| Nick Elson 2006-02-25, 9:41 am |
| > We've noticed that in our tester environment, we still get messages which
> aren't very large at all mixed in with large messages. Am I wrong to
> interpret this as indicating the message size varies with need?
Need and available memory for the sender to form the messages
in.
> On a very bad day, the M size in:
> "{Sending/Received} message (n-nnnnnnnnnn-nnnnnnnnnn-M)"
> can be over 1,000. We had one unfortunate incident where the number was
> greater than the number of message files which can be generated before the
> naming rolls over (starting at .0 and ending at .zzz). Fortunately that
> was in the test envrionment!
That is huge number and very definite indication that you have not set
you -m setting large enough. If so it needs to be 'up to' a 1000x
bigger than the default setting of 2MB] Try it out at 512M or even
a 100MB. You can probably justify buying the extra RAM give
the problems you can avoid.
As mentioned before the consolidated site is the one who usually
needs the extra RAM.
"Carol Stone" <""carol.stone \"@ ctcommunitycare . org"> wrote in message
news:43fbb134$1@foru
ms-1-dub...[color=darkred]
> Good grief, thank you for the info!
>
> We've noticed that in our tester environment, we still get messages which
> aren't very large at all mixed in with large messages. Am I wrong to
> interpret this as indicating the message size varies with need?
>
> On a very bad day, the M size in:
> "{Sending/Received} message (n-nnnnnnnnnn-nnnnnnnnnn-M)"
> can be over 1,000. We had one unfortunate incident where the number was
> greater than the number of message files which can be generated before the
> naming rolls over (starting at .0 and ending at .zzz). Fortunately that
> was in the test envrionment!
>
> Our dialup users are nearly all in-state. And when we expect that 'M' size
> to be really high, we recommend our users drive into the office to use the
> LAN.
>
> This is starting to sound to me like the largest size might be small
> enough for our needs. I think we're going to have to beat up our tester
> environment and see what happens under load testing! Thank you so much for
> the info!
>
> -carol
>
> Nick Elson wrote:
| |
| Carol Stone 2006-02-25, 9:41 am |
| > That is huge number and very definite indication that you have not set
> you -m setting large enough. If so it needs to be 'up to' a 1000x
> bigger than the default setting of 2MB] Try it out at 512M or even
> a 100MB. You can probably justify buying the extra RAM give
> the problems you can avoid.
>
> As mentioned before the consolidated site is the one who usually
> needs the extra RAM.
>
>
Ok, I'm running -m 512M in the test environment for tonight. Let's see
how big a bang that gives us. We've got a lot of memory available on the
server, but I'm not quite sure how to best take advantage of it, because
some of it is paged memory. Should I care?
-carol
| |
| Nick Elson 2006-02-25, 9:41 am |
| > Ok, I'm running -m 512M in the test environment for tonight. Let's see how
> big a bang that gives us. We've got a lot of memory available on the
> server, but I'm not quite sure how to best take advantage of it, because
> some of it is paged memory. Should I care?
If by 'paged memory' you mean 'not real RAM' then yes, you may
care. It can run slower if it starts to actually page out to the
PagingFile.
It may not be significantly slower but you will be at risk of even slower
performance as soon as some new is added which needs more RAM.
That something could be as benign as a hotfix or an I.T. push onto your
machine.
"Carol Stone" <""carol.stone \"@ ctcommunitycare . org"> wrote in message
news:43fcf049$1@foru
ms-1-dub...
>
> Ok, I'm running -m 512M in the test environment for tonight. Let's see how
> big a bang that gives us. We've got a lot of memory available on the
> server, but I'm not quite sure how to best take advantage of it, because
> some of it is paged memory. Should I care?
>
>
> -carol
| |
| Carol Stone 2006-02-25, 9:41 am |
| Nick Elson wrote:
> If by 'paged memory' you mean 'not real RAM' then yes, you may
> care. It can run slower if it starts to actually page out to the
> PagingFile.
Yes, I did mean 'not real RAM.' I think we'll have to just keep an eye
on it. The test went so well that we're going to increase our -m value
in our production environment tomorrow night. This way, if we run into a
major slow down right away, we'll be able to deal with it and nobody
will know the difference!
Thank you very much for all your help on this. The -m switch never
struck us as such an important option. You've worked really hard to get
us to pay attention to it. Thank you.
-carol
|
|
|
|
|