• (cs) in reply to Maj najm
    Maj najm:
    cellocgw:
    Steve The Cynic:
    Calamari ==> Squid...

    And of course "squid" is a double-headed reference...

    It means something besides Superconducting Quantum Interference Detector ?

    Yes, it can mean Stupid, Quick, Underdressed, Imminently Dead motorcyclist as well.

    Evidently I needed to spell it out a bit more explicitly for this supposedly IT-aware audience...

    Context: Web server farm. Calamari => Squid => squid => caching web proxy.

    Duh. Looks like the readership here is TRWTF. (But I knew that anyway...)

  • (cs) in reply to Snooder
    Snooder:
    Valued Service:
    And how does a VP come up with something for Tom to do? That's not how you manage projects.

    Unless you're talking a starup of 20 or less, maybe, and even then, it shouldn't happen often. That's a major sign of a lack of trust and micromanagement.

    Because if the VP and/or owner feels the need to hire middle management, then he shouldn't feel the need to have direct control over the bottom level employees.

    If he needs to have that much direct access to a person, he should move that person under himself, or he is going to negatively impact morale.

    Ugh that's just the worst sort of hidebound corporate thinking. How would it negatively affect morale if the CEO talks to someone low on the totem-pole once in a blue moon? How is being micromanaged by your immediate supervisor any better than being micromanaged by someone in the C-suite?

    Worse, when you get to a situation where the higher ups never ever interact with the guys lower down, you start having issues. First because the CEO type becomes totally disassociated with the actual day-to-day work in the business. And second because the guy at the bottom feels that he has no stake in the company as a whole.

    I'm not saying that every company would benefit from this. Obviously larger organizations with multi-national operations can't do this. And even then, it's not a good management style for the VP to respond to EVERY emergency by camping out in the cubicle of the guy fixing it. But let's take a small company with about 100 employees. The IT department is about 50 guys and has 5 teams of 10 guys each. Do you really think having a guy in the accounting department filter every single communication through the IT director and the team lead is better than just calling the server guy directly on rare occasions?

    Or, in a situation more like this one, if something horrendous happens and the company owner is fielding angry calls from clients, shouldn't the guy fixing the problem report his progress directly to the owner instead of having the IT director report progress based on what the team lead reported to him based on what the guy actually fixing it reported?

    Sure that should be accepted but your direct supervisor should be kept in the loop so that he/she knows wat your doing.

  • Anonymous (unregistered) in reply to bob nelson
    bob nelson:
    [...] of course the proper way to do this is through sysctl with things like:

    vm.swappiness=10 vm.dirty_background_ratio=5 vm.dirty_ratio=80

    ^^^ This. Yes. ^^^

  • poster of the screenshot (unregistered)

    Piping grep into awk? The sick, sick bunnies!

  • poster of the screenshot (unregistered) in reply to Zylon

    Data centre., obviously

  • Stev (unregistered)
    This reeks of Windows thinking.

    This reeks of ignorance. This reeks of someone who doesn't work with windows in any real capacity (or if they do, haven't been properly trained) and so naturally, any WTF-esque thing they see must be windows' fault - even when it's a cron job on a *nix machine.

    I hate this reasoning, Windows can give you the tools to shoot yourself in the foot and that is Windows' fault, but when *nix does it, it's the user at fault. Or in this case, still windows.

  • cros (unregistered) in reply to Black Bart

    The parameter 3 is a bit vector. Therefore "echo 3 > /proc/sys/vm/drop_caches" would suffice.

    It can be useful to release memory from cache if swapping occurs.

    The syscontrol variable vm.swappiness should be adjusted to balance memory usage for caching and swapping. If vm.swappiness is set to 0 swapping will only occur to prevent out of memory conditions.

  • (cs) in reply to oesor
    oesor:
    operagost:
    "LAMP stack"... this reeks of *nix thinking.

    The lesser-known Lindows-AOLServer-Mumps-Postgres stack.

    +1 for throwing AOLServer into the stack, but you got two databases in there!

    The last letter indicates the programming language. So traditionally PHP (which is TRWTF) or Perl (which has lots of regular expressions all over the place, so now you have twolots problems!)

    As a replacement i suggest: "The lesser-known Lindows-AOLServer-Mumps-Postscript stack". A natural fit, as Postscript is a stack-oriented programming language.

  • gktyjfehdesgerg (unregistered) in reply to Mintzberg
    It's funny that some people seem to think that hierarchy is the solution to all organisational issues. It's not and it's proven to be very dependent on organisational culture, which in turn is influenced by things like type of employees (factory worker vs knowledge worker for example), but also country can play a role in this.

    It should be obvious that there is no single solution for every organisation.

    It should be equally obvious that being disturbed by a handful of managers, many of which are unlikely to be in your chain of command, is unhelpful for getting the problem solved.

  • (cs) in reply to cros
    cros:
    The parameter 3 is a bit vector. Therefore "echo 3 > /proc/sys/vm/drop_caches" would suffice.

    It can be useful to release memory from cache if swapping occurs.

    The syscontrol variable vm.swappiness should be adjusted to balance memory usage for caching and swapping. If vm.swappiness is set to 0 swapping will only occur to prevent out of memory conditions.

    I was beginning to wonder if anyone was going to point out that bitmap issue! ;-)

    Imo a bigger WTF than doing trying to flush the cache in the first place because it proves the fool who came up with it never read any the documentation rather than "just" missing the purpose of it.

  • J. Edgar Hoover (unregistered) in reply to cros
    cros:
    The parameter 3 is a bit vector. Therefore "echo 3 > /proc/sys/vm/drop_caches" would suffice.

    It can be useful to release memory from cache if swapping occurs.

    The syscontrol variable vm.swappiness should be adjusted to balance memory usage for caching and swapping. If vm.swappiness is set to 0 swapping will only occur to prevent out of memory conditions.

    Now you see what happens when you drop your caches too many times? I can't even remember who I swappiness with. I have to ask the NSA to manage my memory because my bureau can't handle it.

  • Cheong (unregistered) in reply to Steve The Cynic

    I have a problem... from drop_caches manpages, it seems the effect of 3 equals to 1 plus 2. Why not just run with the "3" option.

  • Haxy (unregistered) in reply to Snooder
    Snooder:
    Valued Service:
    tharpa:
    There are very few rules that fit for all sizes of organizations in all circumstances.

    And this is one of them.

    You only respond to the closest (hierarchically) supervisor available.

    Otherwise, you end up with help-desk, hr, clients, and the IRS at your desk.

    That depends on whether your goal is to get a problem resolved, or to keep from being bothered while you work. In a relatively small organization, having Jim walk over to say "hey Bob, X is broken, you have time to fix it?" is faster than having him talk to his supervisor, who talks to his supervisor, who talks to his supervisor, who talks to your supervisor's supervisor, who talks to your supervisor, who talks to you. And it usually results in better information since it doesn't get garbled through the telephone game.

    It's only when Jim is in an entirely different department, and possibly a different state that having him talk to you directly can introduce more issues.

    In such a "small company", why would you have 4 hierarchal supervisors?

  • Haxy (unregistered) in reply to EvilSnack
    EvilSnack:
    Or, in a situation more like this one, if something horrendous happens and the company owner is fielding angry calls from clients, shouldn't the guy fixing the problem report his progress directly to the owner instead of having the IT director report progress based on what the team lead reported to him based on what the guy actually fixing it reported?
    No, the guy fixing the problem should be fixing the problem. Reports can wait until there is something to report.

    I disagree with this. It's acceptable to have an assessment that can be reported to the company in a catastrophe, and depending on the company it's probably the second thing you would do (the first being verify the problem).

    Yes, you need to do your job to get things fixed or band aided ASAP, but customer support also has a job to do, and "we're not sure what's going on or when it might be fixed" may not be acceptable for a long time depending on your clients.

    As another example, it wouldn't be acceptable for the tech team of a multi-million dollar e-commerce site to report nothing regarding the website being down and when it may be back up.

    You don't need to be bothered with root-cause analysis, but spending 15 minutes determining the scale of the issue and reporting that is pretty much expected.

  • Gechurch (unregistered) in reply to Medinoc
    Medinoc:
    If this is about the file/directory cache (a known problem in Windows), then any head whose main software "loads a bunch of files to memory, keep them there, and doesn't access the disc again" would do it. Because the no-longer-actually-used cache forces the server application to page-out its actually useful memory.

    Have you got a reference to back that up? Because Windows memory management hasn't ever worked like that. The Windows memory manager keeps track of when pages were last touched and when there's memory pressure it's the oldest pages that get paged out first.

    The memory manager doesn't care about what's actually stored in a given page. It certainly doesn't have any special checks to see if it's a file/directory cache and if it is, keep that page hanging around in memory unnecessarily.

  • Slapout (unregistered) in reply to quis
    quis:
    operagost:
    "LAMP stack"... this reeks of *nix thinking.
    I wonder, if you rub the LAMP stack, will a Genie come out? Even more importantly, will he sound like Jim Backus or will he sound like Robin Williams?

    You'll get this: GEnie

  • (cs) in reply to Sigivald
    Sigivald:
    It's not so much "Windows Thinking" (Windows actually uses about the same free/caches/wired setup Unix does; welcome to the Everyone's Been NT For Over A Decade future) as "New To Unix Thinking".

    "Hey, free says we're out of ram! Those "cache" things are using all our memory! Better clear those so we never put anything in swap!"

    I've seen the question come up a hundred times with new Unix users who don't understand (and how would they, when the manpages assume you already know?) what the output of free/top means.

    Ah, yes, man pages: documentation written for people who don't need to read it.

  • Norman Diamond (unregistered) in reply to Haxy
    Haxy:
    Snooder:
    Valued Service:
    tharpa:
    There are very few rules that fit for all sizes of organizations in all circumstances.
    And this is one of them.

    You only respond to the closest (hierarchically) supervisor available.

    Otherwise, you end up with help-desk, hr, clients, and the IRS at your desk.

    That depends on whether your goal is to get a problem resolved, or to keep from being bothered while you work. In a relatively small organization, having Jim walk over to say "hey Bob, X is broken, you have time to fix it?" is faster than having him talk to his supervisor, who talks to his supervisor, who talks to his supervisor, who talks to your supervisor's supervisor, who talks to your supervisor, who talks to you. And it usually results in better information since it doesn't get garbled through the telephone game.

    It's only when Jim is in an entirely different department, and possibly a different state that having him talk to you directly can introduce more issues.

    In such a "small company", why would you have 4 hierarchal supervisors?
    Because corporate politics depends on the personalities of the corporate politicians, not on their quantity.

    Even when it's more efficient for Jim to walk over to Bob and ask for help rather than go through Bob's manager because Bob's manager is on a different continent, corporate politics trump efficiency.

  • Norman Diamond (unregistered) in reply to Gechurch
    Gechurch:
    Medinoc:
    If this is about the file/directory cache (a known problem in Windows), then any head whose main software "loads a bunch of files to memory, keep them there, and doesn't access the disc again" would do it. Because the no-longer-actually-used cache forces the server application to page-out its actually useful memory.
    Have you got a reference to back that up? Because Windows memory management hasn't *ever* worked like that. The Windows memory manager keeps track of when pages were last touched and when there's memory pressure it's the oldest pages that get paged out first.

    The memory manager doesn't care about what's actually stored in a given page. It certainly doesn't have any special checks to see if it's a file/directory cache and if it is, keep that page hanging around in memory unnecessarily.

    Medinoc was talking about Windows's file caching not virtual memory management. Yeah, too many things are getting mixed up in this thread.

    Speaking of file caching, yesterday I had reason to learn about Linux's readahead_early and readahead_later or something like that, but it turned out not to be the cause of the problem I was trying to track down.

  • Terr (unregistered) in reply to KattMan
    Yes yes, get me hooked on cthonics!

    Fishing off Soviet Crimea, Cthonic hooks you!

  • eric bloedow (unregistered)

    A friend in accounting had already told Evan about another acquisition that Hydra was hunting. Seven heads is already too many, he thought. that made me remember a scene in the online comic "order of the stick" where a Hydra passed out because too many heads meant not enough blood getting to its brain(s).

Leave a comment on “Modern Memory Management”

Log In or post as a guest

Replying to comment #:

« Return to Article