Performance DEV Vs QA Vs PRD
Moderators: chulett, rschirm, roy
Performance DEV Vs QA Vs PRD
Hi All,
My jobs are running pretty good in DEV and QA, but not in PRD.
One of my job is running under 15 min in DEV and QA and the same job is taking 90 min in Production.
Please let me know , what could be the main reason?. Please shed some light on it.
Thanks,
Naren.
My jobs are running pretty good in DEV and QA, but not in PRD.
One of my job is running under 15 min in DEV and QA and the same job is taking 90 min in Production.
Please let me know , what could be the main reason?. Please shed some light on it.
Thanks,
Naren.
There could be loads of reasons why this could happen.
Is it just this job that performs badly?
Do you have any other jobs that have a similar logic that run as expected. Does this job take 90mins irrespective of when you run it (peak/offpeak ?)
Could You please tell us more about your job and its design please.
Is it just this job that performs badly?
Do you have any other jobs that have a similar logic that run as expected. Does this job take 90mins irrespective of when you run it (peak/offpeak ?)
Could You please tell us more about your job and its design please.
2 words: Solar Flares!
Validate that at the time of execution (found within your datastage logs) if there were any Solar Flares going on. While you are in the log, write down how much data your job processed, and the time of day.
Consult your astrological maps, and compare it against the first letter of each of the other processes running in PROD at the time your job ran. Don't overlook any process names that may have been running on the Production Database servers you ran against as well. Specifically, Cancer sign related jobs hold a bad oman.
Speak with your networking guy and ask him how his day went, casually mention if the solar flares woke him up during that timeframe and if others complained too. But if he was borned under a Full Moon, then nevermind.
Validate that at the time of execution (found within your datastage logs) if there were any Solar Flares going on. While you are in the log, write down how much data your job processed, and the time of day.
Consult your astrological maps, and compare it against the first letter of each of the other processes running in PROD at the time your job ran. Don't overlook any process names that may have been running on the Production Database servers you ran against as well. Specifically, Cancer sign related jobs hold a bad oman.
Speak with your networking guy and ask him how his day went, casually mention if the solar flares woke him up during that timeframe and if others complained too. But if he was borned under a Full Moon, then nevermind.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Describe the hardware of the three systems. Describe the workload on the three systems - not just the DataStage workload, the total workload. Describe the connectivity to databases of the three systems. Describe the workload on those database servers in the three environments.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 3593
- Joined: Thu Jan 23, 2003 5:25 pm
- Location: Australia, Melbourne
- Contact:
Solar flares - ridiculous! It's much more likely to be the position and fullness of the moon.
I would consider installing a version of ISALite on each environment, running the diagnostic report and then comparing the results. It might show up differences between the environments. If you are on version 8 you should find ISALite on your installation disk or you can download it straight from IBM. ISALite (Information Server Support Assistant) is designed to help diagnose problems. It's likely to end up being something like a network bottleneck or a slow disk I/O or a database bottleneck or an undersized production environment (shared CPUs in a virtual environment) or any of a dozen other reasons.
I would consider installing a version of ISALite on each environment, running the diagnostic report and then comparing the results. It might show up differences between the environments. If you are on version 8 you should find ISALite on your installation disk or you can download it straight from IBM. ISALite (Information Server Support Assistant) is designed to help diagnose problems. It's likely to end up being something like a network bottleneck or a slow disk I/O or a database bottleneck or an undersized production environment (shared CPUs in a virtual environment) or any of a dozen other reasons.
PaulVL wrote:2 words: Solar Flares!
Certus Solutions
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn