Debian 5.0 x64 server crasher ofter (kun ping available) - SW eller HW prob?
Hey,
Jeg har et problem med at min Debian 5.0 x64 server crasher ofte for tiden. De sidste par dage har det været 2 gange om dagen. Jeg har også oplevet problemet på en anden server med samme OS, den kører dog stabilt pt.
Det der sker er, at (det jeg kan se) er apache og sshd dør (mysql og andre services dør nok også - men det kan jeg ikke umiddelbart tjekke).
Det eneste jeg kan er at pinge serveren - og den svarer fint. Jeg bliver derefter nød til at remote power down serveren for at få den i luften igen.
i min /var/log/messages får jeg følgende ca hvert 15 sek.. Er der nogen der ved hvad det er eller er der nogen der ved hvor jeg kan spørge om råds??
Feb 13 18:18:33 ditte kernel: [37443.560831] apache2 D 0000000000000013 0 27571 5457
Feb 13 18:18:33 ditte kernel: [37443.560831] ffff81000856fde0 0000000000000082 ffff810098221000 ffff81013fbd8884
Feb 13 18:18:33 ditte kernel: [37443.560831] ffff810062998f20 ffff810046420200 ffff8100629991a8 0000000200000000
Feb 13 18:18:33 ditte kernel: [37443.560831] ffff81013fbd8880 ffff81000856fe68 00000000ffffffe9 ffff81013fbd8884
Feb 13 18:18:33 ditte kernel: [37443.560831] Call Trace:
Feb 13 18:18:33 ditte kernel: [37443.560831] [] do_path_lookup+0x158/0x1cf
Feb 13 18:18:33 ditte kernel: [37443.560831] [] __mutex_lock_slowpath+0x64/0x9b
Feb 13 18:18:33 ditte kernel: [37443.560831] [] mutex_lock+0xa/0xb
Feb 13 18:18:33 ditte kernel: [37443.560831] [] do_filp_open+0x11a/0x7c4
Feb 13 18:18:33 ditte kernel: [37443.560831] [] autoremove_wake_function+0x0/0x2e
Feb 13 18:18:33 ditte kernel: [37443.560831] [] get_unused_fd_flags+0x71/0x115
Feb 13 18:18:33 ditte kernel: [37443.560831] [] do_sys_open+0x46/0xc3
Feb 13 18:18:33 ditte kernel: [37443.560831] [] system_call_after_swapgs+0x8a/0x8f
Feb 13 18:18:33 ditte kernel: [37443.560831]
Feb 13 18:18:44 ditte kernel: [37458.562303] apache2 D 0000000000000013 0 10904 5457
Er det min apache der får serveren til at crashe? Da den crashede tidligere i dag kunne jeg ikke starte mysql fordi der var løbet tør for plads, og jeg håbede egentlig det var det, der var skyld i det.. Men nu efter at have slettet ~20GB apache logs, så crashede den igen her omkring 18 tiden...
Hvis i har brug for mere info, logs eller whatever, så sig til.
De 2 servere er begge HP (DL180G6 og DL120G6)
Please hjælp, jeg er ved at være træt af de crasher 2 gange dagligt :(
/Goerred
Jeg har et problem med at min Debian 5.0 x64 server crasher ofte for tiden. De sidste par dage har det været 2 gange om dagen. Jeg har også oplevet problemet på en anden server med samme OS, den kører dog stabilt pt.
Det der sker er, at (det jeg kan se) er apache og sshd dør (mysql og andre services dør nok også - men det kan jeg ikke umiddelbart tjekke).
Det eneste jeg kan er at pinge serveren - og den svarer fint. Jeg bliver derefter nød til at remote power down serveren for at få den i luften igen.
i min /var/log/messages får jeg følgende ca hvert 15 sek.. Er der nogen der ved hvad det er eller er der nogen der ved hvor jeg kan spørge om råds??
Feb 13 18:18:33 ditte kernel: [37443.560831] apache2 D 0000000000000013 0 27571 5457
Feb 13 18:18:33 ditte kernel: [37443.560831] ffff81000856fde0 0000000000000082 ffff810098221000 ffff81013fbd8884
Feb 13 18:18:33 ditte kernel: [37443.560831] ffff810062998f20 ffff810046420200 ffff8100629991a8 0000000200000000
Feb 13 18:18:33 ditte kernel: [37443.560831] ffff81013fbd8880 ffff81000856fe68 00000000ffffffe9 ffff81013fbd8884
Feb 13 18:18:33 ditte kernel: [37443.560831] Call Trace:
Feb 13 18:18:33 ditte kernel: [37443.560831] [] do_path_lookup+0x158/0x1cf
Feb 13 18:18:33 ditte kernel: [37443.560831] [] __mutex_lock_slowpath+0x64/0x9b
Feb 13 18:18:33 ditte kernel: [37443.560831] [] mutex_lock+0xa/0xb
Feb 13 18:18:33 ditte kernel: [37443.560831] [] do_filp_open+0x11a/0x7c4
Feb 13 18:18:33 ditte kernel: [37443.560831] [] autoremove_wake_function+0x0/0x2e
Feb 13 18:18:33 ditte kernel: [37443.560831] [] get_unused_fd_flags+0x71/0x115
Feb 13 18:18:33 ditte kernel: [37443.560831] [] do_sys_open+0x46/0xc3
Feb 13 18:18:33 ditte kernel: [37443.560831] [] system_call_after_swapgs+0x8a/0x8f
Feb 13 18:18:33 ditte kernel: [37443.560831]
Feb 13 18:18:44 ditte kernel: [37458.562303] apache2 D 0000000000000013 0 10904 5457
Er det min apache der får serveren til at crashe? Da den crashede tidligere i dag kunne jeg ikke starte mysql fordi der var løbet tør for plads, og jeg håbede egentlig det var det, der var skyld i det.. Men nu efter at have slettet ~20GB apache logs, så crashede den igen her omkring 18 tiden...
Hvis i har brug for mere info, logs eller whatever, så sig til.
De 2 servere er begge HP (DL180G6 og DL120G6)
Please hjælp, jeg er ved at være træt af de crasher 2 gange dagligt :(
/Goerred
Kommentarer24
Hvorfor kører du ikke
Har du prøvet at kører noget hardware test på serveren ?
Hmm, jeg husker ikke så
Jeg har ikke prøvet at køre et hardware check. Det kan jeg godt få gjort, men det vil give mig 4-5 timers downtime og det er jeg ikke interesseret i. Slet ikke hvis det er noget software relateret..
Hvis der ikke er nogen der har et bud på dette, vil alternativet selvfølgelig være at få lavet noget hw dianostigs men det vil jeg meget gerne undvære :-)
Ja så er det ikke så
Har ikke noget klart svar, men giver dmesg noget? Laver den også kernel fejl?
Laver begge servere samme fejllog ?
Jeg har haft kørt et
Jeg synes ikke umiddelbart jeg får nogen fekl i dmesg.
Jeg har dette, kan det have noget at sige, og hvis, what to do?
[ 8.581567] Driver 'sd' needs updating - please use bus_type methods
[ 8.581567] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8.581567] sd 0:0:0:0: [sda] Write Protect is off
[ 8.581567] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8.581567] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 8.581567] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8.581567] sd 0:0:0:0: [sda] Write Protect is off
[ 8.581567] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8.581567] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 8.581567] sda: sda1 sda2 sda3 sda4 < sda5 >
hmmm
HVAD sker der ?
du kan nå pinge kasserne men du kan ikke logge på SSH eller tilgå websites via apache ?
hvornår er dette symptom begyndt, er dette noget der er begyndt for nyligt
hvis ja . har du på nogen måde ændret software for nyligt,
hvilke hardware tests har du kørt ?
Bruger du custom kernel ?
hvis ja hvor længe har du kørt med denne.
Du siger du har løbet tør for plads, sørg for at dette ikke sker,, heller ikke på /tmp det kan give alverdens ballade.
Er det meget belastede servers, har de flere tusinde samtidige brugere, det kunne
være en konfiguration begrænsning.
kerne beskederne ser sære ud, jeg ville hoppe ind på irc.freenode.org i #kernel og i #apache og spørge derinde.
x64 er en term der ikke
det kunne være dine diske..
redeeman, beklager meget at
Nevertheless..
dklinux;
For nyligt har jeg oplevet at mine servere er "crashet". Jeg kan ikke umiddelbart komme i tanke om at jeg har installeret ekstra software, men jeg har opdateret OS'et med de opdateringer der er kommet hertil og til det software som er installeret (Det kunne fx være apache, mysql og php).
Jeg oplevede det 2-3 gange på min "store kasse (HPDL180G6)". Det er nu noget tid siden det er sket der. Nu er det så "begyndt" på min "lille kasse (HPDL120G6).
Når serverne er "crashet" har jeg ikke haft mulighed for at logge på dem via ssh eller tilgå dem via apache. Jeg har kunne pinge serverne og de har svaret fint med en ok latency.
Jeg har haft mit datacenter til at køre hardware test på dem. Der er blevet testet RAM, CPU og MB.
I min "lille kasse" kører jeg med software raid. 1 stk RAID 1 og 1. stk RAID 0. Jeg har tjekket med SMART og diskene pass'er. Jeg har dog forsøgt at lave en long test, men den bliver stående ved "90% remaining". Hvad kan det skyldes?
På den "store kasse" er der ingen raids der er degrated.
Ja, den var løbet tør for plads på / og hvor de andre os relaterede partitioner er. Dette er der nu taget forbehold for og der er rigeligt med plads.
Serverne er en del belastende. Ligger omkring 300-500 requests i sekundet (mysql og apache).
På min "lille kasse" ligger cpu wait'en på omkring 10-20%. Det er ret meget. Jeg går udfra at det er wait på at skrive til diskene. Kan det være det, der er skyld i det?
Jeg vil forsøge at hoppe ind på de channels og høre der, som de beskriver. Hvad er det, der gør det ser sjovt ud?
Setup'et:
Server1:
HP DL120 G6
2x Intel Xeon X3440 2,5 ghz
4 GB Ram
2x80GB Software RAID 1
2x2TB Software RAID 0
Kører hovedsagdeligt: mysql og apache
Er installeret med Debian GNU/Linux 5.0
2.6.26-2-amd64
Server2:
HP DL180 G6
2x Intel Xeon E5504 2,0 ghz
8GB Ram
2x2TB Hardware RAID 1 til OS
9x2TB Hardware RAID 50 (3 RAID5-subsets)
1x2TB Hardware RAID Hot Spare
Kører hovedsageligt: apache
Er installeret med Debian GNU/Linux 6.0
2.6.32-5-amd64
Andet info nødvendigt? :-)
jeg svarede dig på hvad
jeg svarede dig på hvad der virker som den mest sansynelieg årsag..
desuden er det ikke "x86-64", men "x86_64" nu vi er igang....
og hvis din smart test bliver stående kan det betyde disken er istykker, eller måske den ikke kan lide nogle kommandoer der blev sendt imens disken kørte testen.. kørte du smart testen online?
#8 ok.
Jeg vil tro det er en
Jeg vil tro det er en offline test, men ved ikke hvornår/hvordan den køres?
Men vil tro den er kørt nu:
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 8496 -
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Kører den på den anden disk i raid'et nu.
Men skal den meldes ud af RAID'et først, før det kan køres ordentligt? Bruger smartctl - har ikke rigtig brugt det før
nogle diske kan fint
send forresten også komplet
ditte:/home/rasmus# smartctl
ditte:/home/rasmus# smartctl -a /dev/sda
smartctl version 5.38 [x86_64-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.10 family
Device Model: ST380815AS
Serial Number: 9QZE4XB2
Firmware Version: 4.AAB
User Capacity: 80,026,361,856 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 7
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Wed Feb 15 21:58:37 2012 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 430) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 27) minutes.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 253 006 Pre-fail Always - 0
3 Spin_Up_Time 0x0003 097 097 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 27
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 084 060 030 Pre-fail Always - 295249584
9 Power_On_Hours 0x0032 091 091 000 Old_age Always - 8517
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 27
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 068 064 045 Old_age Always - 32 (Lifetime Min/Max 30/32)
194 Temperature_Celsius 0x0022 032 036 000 Old_age Always - 32 (0 17 0 0)
195 Hardware_ECC_Recovered 0x001a 073 072 000 Old_age Always - 191858279
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0
202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 8496 -
# 2 Extended offline Interrupted (host reset) 90% 8488 -
# 3 Short offline Completed without error 00% 0 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
og den anden disk i raid 1'et:
ditte:/home/rasmus# smartctl -a /dev/sdb
smartctl version 5.38 [x86_64-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.10 family
Device Model: ST380815AS
Serial Number: 9QZE8E9B
Firmware Version: 4.AAB
User Capacity: 80,026,361,856 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 7
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Wed Feb 15 21:59:49 2012 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 249) Self-test routine in progress...
90% of test remaining.
Total time to complete Offline
data collection: ( 430) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 27) minutes.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 253 006 Pre-fail Always - 0
3 Spin_Up_Time 0x0003 097 097 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 24
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 084 060 030 Pre-fail Always - 291876366
9 Power_On_Hours 0x0032 091 091 000 Old_age Always - 8516
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 24
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 068 062 045 Old_age Always - 32 (Lifetime Min/Max 30/32)
194 Temperature_Celsius 0x0022 032 038 000 Old_age Always - 32 (0 18 0 0)
195 Hardware_ECC_Recovered 0x001a 074 072 000 Old_age Always - 32433826
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0
202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 0 -
# 2 Extended offline Self-test routine in progress 90% 8514 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
edit:
Raid'et er også clean:
ditte:/home/rasmus# mdadm --detail /dev/md2
/dev/md2:
Version : 00.90
Creation Time : Thu Feb 24 14:29:26 2011
Raid Level : raid1
Array Size : 73850688 (70.43 GiB 75.62 GB)
Used Dev Size : 73850688 (70.43 GiB 75.62 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 2
Persistence : Superblock is persistent
Update Time : Wed Feb 15 22:04:53 2012
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : db6da440:c69c1047:56eb4d79:f116177f
Events : 0.66
Number Major Minor RaidDevice State
0 8 5 0 active sync /dev/sda5
1 8 21 1 active sync /dev/sdb5
editedit:
Kan det have noget at gøre med dette? Det kan vel give det wait på disken der er, hvis det sluger helt åndssvagt:
ditte:/home/rasmus# iotop
Total DISK READ: 298.45 K/s | Total DISK WRITE: 2.58 M/s
PID USER DISK READ DISK WRITE SWAPIN IO> COMMAND
11968 root 34.88 K/s 0 B/s 0.00 % 23.98 % find /var/lib/php5/ -type f -cmin +24 -delete
6060 root 42.64 K/s 0 B/s 0.00 % 21.66 % find /var/lib/php5/ -type f -cmin +24 -delete
1340 root 0 B/s 2.57 M/s 0.00 % 16.48 % [kjournald]
16186 root 46.51 K/s 0 B/s 0.00 % 14.36 % find /var/lib/php5/ -type f -cmin +24 -delete
2809 root 38.76 K/s 0 B/s 0.00 % 11.83 % find /var/lib/php5/ -type f -cmin +24 -delete
Altså find'en. Det er noget med nogle gamle session filer den cleaner, kan og skal det tage så meget IO?
jeg ville desværre gerne
Jeg følger dog jeg skylder dig at lade dig vide jeg ikke vil svare dig her på siden, så du ikke sidder og venter.
Ehhh what the fuck?
Ehhh what the fuck? Giver da ingen mening!?!
Suk :(
Nå, back on track! I
Nå, back on track! I need help :)
Hey,
Jeg fik lige vide af
Jeg fik lige vide af Marlar (site admin) at Redeeman IKKE er blokeret af admin
(iøvrig har jeg ikke mulighed for at blokere brugere som moderator selv, kun give dem advarsler, og banne efter et vist antal klager sendt fra andre brugere etc....det er en forum funktion, bare spørg Marlar).
Men helt sikkert, blokeret BURDE du være med den opførsel du har lagt for dage i de mange tråde du har brokket dig højlydt med ubekvemsord etc.
Som sagt i den andre tråd, du skal være velkommen tilbage NÅR og HVIS du kan opføre dig som du f.eks startede med i denne tråd. Og ikke hetze visse brugere.
EOD.
Ja, absolut, hvis det
Kan i ikke please bruge den
Jeg har ingen som heldst
Det jeg kan som moderator er:
- Slet (enkelt post)
- Edit (enkelt post)
- Klikke på en funktion som hedder ANMELD MODERERING, det er så en kø af inkomne anklager fra folk, hvor jeg så får en række options, IGNORE, WARN, DELETE, etc...
That's it,
Iøvrig har jeg fået RIGTIG mange anmeldelser fra brugere på dine indlæg tidligere, og jeg har været ALDELES for tolerant ved dig, men når du omsider får en eller to indlæg modereret, så går du i "hate-mode" og opretter tråde om mig etc... altså , hallåh...hvor vil du egentlig hen?
Fordi du har trykket på
Og ja, du har sagt mange ting der ikke er korrekt:
Her er to af de værste:
#1 - du har oprettet en post hvor du anklager mig for at benytte falsk email adresse, det var så IKKE korrekt da det var Skunks email adresse der var forbundet til LinuxIN.dk's automatiske meldings system, og du skrev så i OFFENTLIG FORUM at jeg sendte mails til dig med falsk afsender.
#2 - Du har nu også anklaget mig for at jeg har blokeret dig, hvilket jeg ikke havde gjord, og du oprettet dig som endnu en bruger bare for at forfølge mig i enhver tråd, og skrive til alle at "buuhuu joongle har modereret / blokeret mig". Å herre jeebuz rebus for en opførsel.
Og hold nu op med det korstog! NU!
Apache ser ud til at være problemet.
Det ser i mine øjne ud som om det er apache der ikke opfører sig ordenligt. Hvis der er en opdatering til Apache så installer den.
Har du anelse om dette er opstået som følge af en opdatering (tjek evt /var/log/apt/history.log) hvis du ikke kan huske det. Tjek også apache's logfiler for om der har været nogen usedvanelig traffik på sitet der kan have fremprovokeret en ellen anden fejl/overforbrug af ressourcer.
vh Lasse
BACK ON TRACK
Goerred jeg vil give Lasse ret ,, men det er måske i virkeligheden bare det er en fælles nævneren mellem maskinerne.
Det er dog meget irriterende at du også mister din SSH forbindelse , jeg synes du skal holde grundigt øje med dine logs for SSHD og HTTPD og prøv at se om du ikke kan backtracke og finde ud af hvad der forgår omkring tidspunktet hvor de går ned.
At du mister SSHD også tyder på et mere generelt problem dog, typisk diskplads mangel eller whatnot, måske var det en ide at du fik SSH til at snakke ekstra meget og fortælle dig hvorfor den ikke vil lade dig logge på.
En mere irriterende ting der kunne ske var at du flytter så meget data at dit datacenter har en iptables regel eller loadbalancer der blokerer din traffik over TCP , men ikke ping som er ICMP.
Det vil være rigtigt godt igen at være helt klar over hvad der forgår, ryger SSHD og HTTPD NED ? eller er de bare ikke tilgængelige pga af I/O eller netværks problemer.
Det lader til at du har en del traffik, jeg ved om iotop er alarmerende. Sker dette her kun under høj load ?
den ting der falder i mine øjne ved iotop er din kjournald der skriver en del data til din journal ,
1340 root 0 B/s 2.57 M/s 0.00 % 16.48 % [kjournald]
altså ihvertfald hvis dette her er noget der står på i mere end et sekunds tid. Jeg går ud fra at du bruger ext3 med almindelig journal på dit filsystem. Jeg fandt nogle ret interessante links på nettet .
http://www.redhat.com/archives/ext3-users/2002-October/msg00023.html
her er en gut med kjournalds der simpelthen dør
http://www.redhat.com/archives/ext3-users/2010-June/msg00008.html
normaltvis er det ikke noget man ser ske,, men du har temmeligt meget diskplads
her er der et generelt spørgsmål omkring kjournald load,
Jeg vil gerne vide om du ser meget io load via kjournald og om dette process også bruger meget CPU ? Det er dog sandsynligt at på dine maskiner vil apache , mysql og PHP overdøve den CPU mæssigt.
Hvis du kan sætte en logging op sådan at du kan hive cpu load , network bandwidth, transactions på apaches , mysql , og iotop data ud over tid , og så se om der er sammenfald.
Du sagde at det er stoppet med at ske på din store box, stoppede det efter at du fordelte load til den lille box ? Eller va der andet der skete der.
Hej guys, tak for
Lasse, Mit umiddelbare bud var også apache, og ja, det er da ikke lang tid siden at der var opdateringer til apache og mysql. De blev selvfølgelig opdateret og det er jo også derefter det er begyndt at ske. Om det er pga opdateringerne det ved jeg ikke. Men efter det begyndte at ske er der kommet en yderligere update til apache - opdateret uden hjælp.
dklinux, jeg tror ikke at at det er mit datacenter (Leaseweb) der blocker for det. Jeg har ikke så meget dataforbrug på "den lille kasse", dog en del connections. Den anden har flere tb's trafik om måneden og det er ikke og har aldrig været et problem (så længe man betaler for det jo :-))
Jeg tror også det er noget med IO'en på disken at gøre. Det er kun 7200rpm sata2 diske der sidder i den, og så med software raid - måske det er det, der ligger den ned?
Men hvad er det, i min journal der logger så meget? Jeg har slået apache access log fra så den ikke kværner disken i bund.
kjournal står ikke på i meget mere end 1 sekund tids af gangen men kommer flere gange, hurtigt efter hinanden.
MEN... i går aftes flyttede vi databasen og vores webserver derfra til den anden. Nu er IO'en på diskene faldet og serveren er ikke crashet siden...
I og med der ikke er fundet fejl på cpu eller ram og det ikke har været ualmindelig meget loaded, vil jeg tro det er diskene!.
Datacenteret anbefalede en reinstallering af serveren.. Jeg tror vi får smidt nogle SSD diske i (2x RAID 1) hvor SQL kan få lov at køre på et set for sig selv og apache på det andet.
Efter vi har flyttet det hele til den anden kasse, så kører det ok. Samme antal connections og ingen problemer. Det er også SATA2 7200 diske der sidder der i, men det er et HW raid... Er software raid'et i debian bare ikke hurtigt nok? :( Der er dog en stadig lidt wait nu på diskene nu, men ikke så slemt og sitet performer bedre:
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 1 55740 1592860 130752 4939284 1 2 180 103 16 23 1 1 98 1
0 5 55732 1590816 131296 4939868 0 0 1088 2208 4104 2771 1 1 73 25
1 5 55732 1589344 134660 4940272 0 0 3412 0 4878 4932 1 1 70 28
0 1 55732 1583124 140884 4940740 0 0 6204 92 6043 6607 1 2 74 23
0 1 55732 1513572 144504 4940964 0 0 3540 32628 5360 4409 1 4 89 5
0 1 55732 1456404 144704 4941720 0 0 624 51888 3968 3304 2 7 84 7
0 0 55732 1455732 144772 4942828 0 0 648 1672 3720 3061 1 1 89 9
0 0 55732 1545164 144772 4943132 0 0 0 0 4009 4349 1 1 98 0
0 0 55732 1544060 145304 4944232 0 0 1332 0 4441 5977 1 1 96 2
0 0 55732 1455896 145444 4944644 0 0 292 0 3331 2825 2 2 96 0
0 0 55732 1455144 145448 4945300 0 0 252 0 3323 3060 1 1 97 0
0 0 55732 1309276 145464 4945420 0 0 0 93256 3658 3239 2 3 94 1
0 0 55732 1311424 145584 4946068 0 0 328 0 3880 4472 1 1 98 0
0 0 55732 1459116 145600 4946576 0 0 452 0 3677 3323 1 1 97 1
0 0 55732 1461148 145608 4947232 0 0 0 44 3348 2767 1 1 98 0
0 0 55732 1549388 145632 4947948 0 0 376 0 3334 3015 1 1 97 1
root@tea:/home/rasmus# /etc/init.d/mysql status
Server version 5.0.51a-24+lenny5
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /var/run/mysqld/mysqld.sock
Uptime: 18 hours 37 min 58 sec
Threads: 224 Questions: 13589258 Slow queries: 410 Opens: 13823 Flush tables: 1 Open tables: 64 Queries per second avg: 202.589.
HW Raid er at foretrække
Naturligvis skal du have harddiskplads nok ...
Hvis du vælger SSD, så er det efterfølgende ikke aktuelt, men hvis ikke, så findes det intet bedre til at tjekke, og reparere HDD's fysiske tilstand end SpinRite. Et værktøj man skal have med i værktøjskassen (sata).
https://www.grc.com/sr/spinrite.htm