On 10/26/2016 03:33 PM, Gordon Messmer wrote:
On 10/24/2016 03:16 PM, Joe Zeff wrote:
I don't have the experience to judge which one is better; I was only
pointing out a reason that you'd not want multiple instances of the
database program working on the same file at any given time.
Yes, but
On 10/24/2016 03:16 PM, Joe Zeff wrote:
I don't have the experience to judge which one is better; I was only
pointing out a reason that you'd not want multiple instances of the
database program working on the same file at any given time.
Yes, but I wasn't proposing starting multiple instance
On 10/24/2016 03:16 PM, Joe Zeff wrote:
> On 10/24/2016 02:34 PM, Gordon Messmer wrote:
>>
>> Yes, I get that. But why would it be better for the scheduler to start
>> up database servers on multiple hosts and allow them to compete for a
>> lock, rather than pick one host to start the database and
On 10/24/2016 02:34 PM, Gordon Messmer wrote:
Yes, I get that. But why would it be better for the scheduler to start
up database servers on multiple hosts and allow them to compete for a
lock, rather than pick one host to start the database and start one
instance? The former is what JD is sugg
On 10/24/2016 02:07 PM, Joe Zeff wrote:
A database running on a server probably doesn't want more than one
process to be modifying it at any given time.
Yes, I get that. But why would it be better for the scheduler to start
up database servers on multiple hosts and allow them to compete for
On 10/24/2016 01:28 PM, Gordon Messmer wrote:
I honestly can't think of any good reason to spawn multiple children
that compete for a lock to do work, when the process that's starting
them*should* have adequate information about which clients are active
and which are idle, and can use that infor
On Sat, Oct 22, 2016 at 1:00 PM, jd1008 wrote:
> Parallel server processes:
> The server process might be coded so that for each request, it forks a child
> process to serve the request.
> Now, child processes have to compete for a lock on the list of files to be
> served, one of the children will
On 10/22/2016 03:13 PM, bruce wrote:
> I've thought of having a "pid" file on the nfs, where each clientApp
> would reset/lock/use the pidFile to then get/use/delete the file as
> required, but this seems tb slow.. but doable.
I would experiment with using the atomicity of the filesystem rename.
On 10/22/2016 02:39 PM, bruce wrote:
On Sat, Oct 22, 2016 at 4:00 PM, jd1008 wrote:
On 10/22/2016 12:14 PM, Gordon Messmer wrote:
On 10/22/2016 06:13 AM, bruce wrote:
I've thought of having a "pid" file on the nfs, where each clientApp
would reset/lock/use the pidFile to then get/use/delet
On Sat, Oct 22, 2016 at 4:00 PM, jd1008 wrote:
>
>
> On 10/22/2016 12:14 PM, Gordon Messmer wrote:
>>
>> On 10/22/2016 06:13 AM, bruce wrote:
>>
>>> I've thought of having a "pid" file on the nfs, where each clientApp
>>> would reset/lock/use the pidFile to then get/use/delete the file as
>>> requ
On 10/22/2016 12:14 PM, Gordon Messmer wrote:
On 10/22/2016 06:13 AM, bruce wrote:
I've thought of having a "pid" file on the nfs, where each clientApp
would reset/lock/use the pidFile to then get/use/delete the file as
required, but this seems tb slow.. but doable.
Probably. You'd have a
On 10/22/2016 06:13 AM, bruce wrote:
The idea, is that a clientApp, on a given clientVM will access a file
on the nfs, and then the nfs file is no long used.
It's difficult to offer performance tuning advice without more
information about what the app is doing, exactly. Is it reading it into
Hey List.
This is off topic, but I noticed the list has been quiet!!
Trying to get different thoughts on how to approach an issue.
I've got a situation, where I'm going to have a shared nfs, with a
bunch of files..
I'm going to have multiple client boxes/(vms) with each client,
running apps tha
13 matches
Mail list logo
